diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/01-About.md | 7 | ||||
| -rw-r--r-- | doc/02-Installation.md | 12 | ||||
| -rw-r--r-- | doc/03-Configuration.md | 120 | ||||
| -rw-r--r-- | doc/04-Upgrading.md | 106 | ||||
| -rw-r--r-- | doc/05-Distributed-Setups.md | 16 | ||||
| -rw-r--r-- | doc/TRADEMARKS.md | 13 | ||||
| -rw-r--r-- | doc/images/icingadb-architecture.png | bin | 563761 -> 454289 bytes | |||
| -rw-r--r-- | doc/images/icingadb-daemon.png | bin | 527021 -> 419862 bytes | |||
| -rw-r--r-- | doc/images/icingadb-database.png | bin | 528639 -> 418924 bytes | |||
| -rw-r--r-- | doc/images/icingadb-envs.png | bin | 660235 -> 470088 bytes | |||
| -rw-r--r-- | doc/images/icingadb-ha.png | bin | 642860 -> 764923 bytes | |||
| -rw-r--r-- | doc/images/icingadb-web.png | bin | 532529 -> 424776 bytes |
12 files changed, 210 insertions, 64 deletions
diff --git a/doc/01-About.md b/doc/01-About.md index 8211e57..056da3f 100644 --- a/doc/01-About.md +++ b/doc/01-About.md @@ -3,13 +3,14 @@ Icinga DB is a set of components for publishing, synchronizing and visualizing monitoring data in the Icinga ecosystem, consisting of: -* The Icinga DB daemon, which synchronizes monitoring data between a Redis server and a database +* The Icinga DB daemon, + which synchronizes monitoring data between a Redis®[\*](TRADEMARKS.md#redis) server and a database * Icinga 2 with its [Icinga DB feature](https://icinga.com/docs/icinga-2/latest/doc/14-features/#icinga-db) enabled, - responsible for publishing the data to the Redis server, i.e. configuration and its runtime updates, check results, + responsible for publishing the data to the Redis® server, i.e. configuration and its runtime updates, check results, state changes, downtimes, acknowledgements, notifications, and other events such as flapping * And Icinga Web with the [Icinga DB Web](https://icinga.com/docs/icinga-db-web) module enabled, - which connects to both Redis and the database to display and work with the most up-to-date data + which connects to both Redis® and the database to display and work with the most up-to-date data  diff --git a/doc/02-Installation.md b/doc/02-Installation.md index 8e04a1f..d5bd20b 100644 --- a/doc/02-Installation.md +++ b/doc/02-Installation.md @@ -12,15 +12,15 @@ see the [Upgrading](04-Upgrading.md) documentation for the necessary steps.  Before installing Icinga DB, make sure you have installed [Icinga 2](https://icinga.com/docs/icinga-2), -set up a Redis server, and enabled the `icingadb` feature. +set up a Redis® server, and enabled the `icingadb` feature. The Icinga 2 installation documentation covers all the necessary steps. Additionally, Icinga offers the `icingadb-redis` package for all supported operating systems, -which ships an up-to-date Redis server version and is pre-configured for the Icinga DB components. +which ships an up-to-date Redis® open source server version and is pre-configured for the Icinga DB components. !!! tip Although Icinga DB can run anywhere in an Icinga environment, - we recommend to install it where the corresponding Icinga 2 node and Redis server is running to + we recommend to install it where the corresponding Icinga 2 node and Redis® server is running to keep latency between the components low. <!-- {% else %} --> @@ -271,7 +271,7 @@ psql -U icingadb icingadb < /usr/share/icingadb/schema/pgsql/schema.sql Icinga DB installs its configuration file to `/etc/icingadb/config.yml`, pre-populating most of the settings for a local setup. Before running Icinga DB, -adjust the Redis and database credentials and, if necessary, the connection configuration. +adjust the Redis® and database credentials and, if necessary, the connection configuration. The configuration file explains general settings. All available settings can be found under [Configuration](03-Configuration.md). @@ -286,8 +286,8 @@ systemctl enable --now icingadb ## Installing Icinga DB Web -With Icinga 2, Redis, Icinga DB and the database fully set up, it is now time to install Icinga DB Web, -which connects to both Redis and the database to display and work with the monitoring data. +With Icinga 2, Redis®, Icinga DB and the database fully set up, it is now time to install Icinga DB Web, +which connects to both Redis® and the database to display and work with the monitoring data.  diff --git a/doc/03-Configuration.md b/doc/03-Configuration.md index af92783..21edcf5 100644 --- a/doc/03-Configuration.md +++ b/doc/03-Configuration.md @@ -3,45 +3,65 @@ The configuration is stored in `/etc/icingadb/config.yml`. See [config.example.yml](../config.example.yml) for an example configuration. -## Redis Configuration +## Redis® Configuration -Connection configuration for the Redis server where Icinga 2 writes its configuration, state and history items. +Connection configuration for the Redis® server where Icinga 2 writes its configuration, state and history items. This is the same connection as configured in the [Icinga DB feature](https://icinga.com/docs/icinga-2/latest/doc/14-features/#icinga-db) of -the corresponding Icinga 2 node. High availability setups require a dedicated Redis server per Icinga 2 node and +the corresponding Icinga 2 node. High availability setups require a dedicated Redis® server per Icinga 2 node and therefore a dedicated Icinga DB instance that connects to it. -| Option | Description | -|----------|------------------------------------------------------------------------------------------------------------------------------------| -| host | **Required.** Redis host or absolute Unix socket path. | -| port | **Optional.** Redis port. Defaults to `6380` since the Redis server provided by the `icingadb-redis` package listens on that port. | -| password | **Optional.** The password to use. | -| tls | **Optional.** Whether to use TLS. | -| cert | **Optional.** Path to TLS client certificate. | -| key | **Optional.** Path to TLS private key. | -| ca | **Optional.** Path to TLS CA certificate. | -| insecure | **Optional.** Whether not to verify the peer. | +| Option | Description | +|----------|-------------------------------------------------------------------------------------------------------------------------| +| host | **Required.** Host name or address, or absolute Unix socket path. | +| port | **Optional.** TCP port. Defaults to `6380` matching the Redis® open source server port in the `icingadb-redis` package. | +| password | **Optional.** Authentication password. | +| tls | **Optional.** Whether to use TLS. | +| cert | **Optional.** Path to TLS client certificate. | +| key | **Optional.** Path to TLS private key. | +| ca | **Optional.** Path to TLS CA certificate. | +| insecure | **Optional.** Whether not to verify the peer. | ## Database Configuration Connection configuration for the database to which Icinga DB synchronizes monitoring data. This is also the database used in -[Icinga DB Web](https://icinga.com/docs/icinga-db/latest/icinga-db-web/doc/01-About/) to view and work with the data. +[Icinga DB Web](https://icinga.com/docs/icinga-db-web) to view and work with the data. In high availability setups, all Icinga DB instances must write to the same database. -| Option | Description | -|----------|--------------------------------------------------------------------------------------------------------| -| type | **Optional.** Either `mysql` (default) or `pgsql`. | -| host | **Required.** Database host or absolute Unix socket path. | -| port | **Optional.** Database port. By default, the MySQL or PostgreSQL port, depending on the database type. | -| database | **Required.** Database name. | -| user | **Required.** Database username. | -| password | **Optional.** Database password. | -| tls | **Optional.** Whether to use TLS. | -| cert | **Optional.** Path to TLS client certificate. | -| key | **Optional.** Path to TLS private key. | -| ca | **Optional.** Path to TLS CA certificate. | -| insecure | **Optional.** Whether not to verify the peer. | +| Option | Description | +|----------|------------------------------------------------------------------------------------------------------------------------------------------------| +| type | **Optional.** Either `mysql` (default) or `pgsql`. | +| host | **Required.** Database host or absolute Unix socket path. | +| port | **Optional.** Database port. By default, the MySQL or PostgreSQL port, depending on the database type. | +| database | **Required.** Database name. | +| user | **Required.** Database username. | +| password | **Optional.** Database password. | +| tls | **Optional.** Whether to use TLS. | +| cert | **Optional.** Path to TLS client certificate. | +| key | **Optional.** Path to TLS private key. | +| ca | **Optional.** Path to TLS CA certificate. | +| insecure | **Optional.** Whether not to verify the peer. | +| options | **Optional.** List of low-level [database options](#database-options) that can be set to influence some Icinga DB internal default behaviours. | + +### Database Options + +Each of these configuration options are highly technical with thoroughly considered and tested default values that you +should only change when you exactly know what you are doing. You can use these options to influence the Icinga DB default +behaviour, how it interacts with databases, thus the defaults are usually sufficient for most users and do not need any +manual adjustments. + +!!! important + + Do not change the defaults if you do not have to! + +| Option | Description | +|--------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------| +| max_connections | **Optional.** Maximum number of database connections Icinga DB is allowed to open in parallel if necessary. Defaults to `16`. | +| max_connections_per_table | **Optional.** Maximum number of queries Icinga DB is allowed to execute on a single table concurrently. Defaults to `8`. | +| max_placeholders_per_statement | **Optional.** Maximum number of placeholders Icinga DB is allowed to use for a single SQL statement. Defaults to `8192`. | +| max_rows_per_transaction | **Optional.** Maximum number of rows Icinga DB is allowed to `SELECT`,`DELETE`,`UPDATE` or `INSERT` in a single transaction. Defaults to `8192`. | +| wsrep_sync_wait | **Optional.** Enforce [Galera cluster](#galera-cluster) nodes to perform strict cluster-wide causality checks. Defaults to `7`. | ## Logging Configuration @@ -56,19 +76,19 @@ Configuration of the logging component used by Icinga DB. ### Logging Components -| Component | Description | -|-------------------|--------------------------------------------------------------------------------| -| config-sync | Config object synchronization between Redis and MySQL. | -| database | Database connection status and queries. | -| dump-signals | Dump signals received from Icinga. | -| heartbeat | Icinga heartbeats received through Redis. | -| high-availability | Manages responsibility of Icinga DB instances. | -| history-sync | Synchronization of history entries from Redis to MySQL. | -| overdue-sync | Calculation and synchronization of the overdue status of checkables. | -| redis | Redis connection status and queries. | -| retention | Deletes historical data that exceed their configured retention period. | -| runtime-updates | Runtime updates of config objects after the initial config synchronization. | -| telemetry | Reporting of Icinga DB status to Icinga 2 via Redis (for monitoring purposes). | +| Component | Description | +|-------------------|---------------------------------------------------------------------------------| +| config-sync | Config object synchronization between Redis® and MySQL. | +| database | Database connection status and queries. | +| dump-signals | Dump signals received from Icinga. | +| heartbeat | Icinga heartbeats received through Redis®. | +| high-availability | Manages responsibility of Icinga DB instances. | +| history-sync | Synchronization of history entries from Redis® to MySQL. | +| overdue-sync | Calculation and synchronization of the overdue status of checkables. | +| redis | Redis® connection status and queries. | +| retention | Deletes historical data that exceed their configured retention period. | +| runtime-updates | Runtime updates of config objects after the initial config synchronization. | +| telemetry | Reporting of Icinga DB status to Icinga 2 via Redis® (for monitoring purposes). | ## Retention @@ -83,6 +103,8 @@ allowing to keep this information for longer with a smaller storage footprint. |--------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | history-days | **Optional.** Number of days to retain historical data for all history categories. Use `options` in order to enable retention only for specific categories or to override the retention days configured here. | | sla-days | **Optional.** Number of days to retain historical data for SLA reporting. | +| interval | **Optional.** Interval for periodically cleaning up the historical data, defined as [duration string](#duration-string). Defaults to `"1h"`. | +| count | **Optional.** Number of old historical data a single query can delete in a `"DELETE FROM ... LIMIT count"` manner. Defaults to `5000`. | | options | **Optional.** Map of history category to number of days to retain its data. Available categories are `acknowledgement`, `comment`, `downtime`, `flapping`, `notification`, `sla` and `state`. | ## Appendix @@ -91,3 +113,21 @@ allowing to keep this information for longer with a smaller storage footprint. A duration string is a sequence of decimal numbers and a unit suffix, such as `"20s"`. Valid units are `"ms"`, `"s"`, `"m"` and `"h"`. + +### Galera Cluster + +Icinga DB expects a more consistent behaviour from its database than a +[Galera cluster](https://mariadb.com/kb/en/what-is-mariadb-galera-cluster/) provides by default. To accommodate this, +Icinga DB sets the [wsrep_sync_wait](https://mariadb.com/kb/en/galera-cluster-system-variables/#wsrep_sync_wait) system +variable for all its database connections. Consequently, strict cluster-wide causality checks are enforced before +executing specific SQL queries, which are determined by the value set in the `wsrep_sync_wait` system variable. +By default, Icinga DB sets this to `7`, which includes `READ, UPDATE, DELETE, INSERT, REPLACE` query types and is +usually sufficient. Unfortunately, this also has the downside that every single Icinga DB query will be blocked until +the cluster nodes resynchronise their states after each executed query, and may result in degraded performance. + +However, this does not necessarily have to be the case if, for instance, Icinga DB is only allowed to connect to a +single cluster node at a time. This is the case when a load balancer does not randomly route connections to all the +nodes evenly, but always to the same node until it fails, or if your database cluster nodes have a virtual IP address +fail over assigned. In such situations, you can set the `wsrep_sync_wait` system variable to `0` in the +`/etc/icingadb/config.yml` file to disable it entirely, as Icinga DB doesn't have to wait for cluster +synchronisation then. diff --git a/doc/04-Upgrading.md b/doc/04-Upgrading.md index 5a085e0..74382e5 100644 --- a/doc/04-Upgrading.md +++ b/doc/04-Upgrading.md @@ -3,6 +3,98 @@ Specific version upgrades are described below. Please note that version upgrades are incremental. If you are upgrading across multiple versions, make sure to follow the steps for each of them. +## Upgrading to Icinga DB v1.2.0 + +Please apply the `1.2.0.sql` upgrade script to your database. For package installations, you can find this file at +`/usr/share/icingadb/schema/mysql/upgrades/` or `/usr/share/icingadb/schema/pgsql/upgrades/`, depending on your +database vendor. + +As the daemon checks the schema version, the recommended way to perform the upgrade is to stop the daemon, apply the +schema upgrade and then start the new daemon version. If you want to minimize downtime as much as possible, it is safe +to apply this schema upgrade while the Icinga DB v1.1.1 daemon is still running and then restart the daemon with the +new version. Please keep in mind that depending on the distribution, your package manager may automatically attempt to +restart the daemon when upgrading the package. + +!!! warning + + With MySQL and MariaDB, a locking issue can occur if the schema upgrade is applied while the history view is + accessed in Icinga DB Web. This can result in the upgrade being delayed unnecessarily and blocking other queries. + Please see [unblock history tables](#unblock-history-tables) for how to detect and resolve this situation. + +### Upgrading the state_history Table + +This release includes fixes for hosts and services reaching check attempt 256. However, on existing installations, +the schema upgrade required to fix the history tables isn't automatically applied by `1.2.0.sql` as a rewrite of the +whole `state_history` table is required. This can take a lot of time depending on the history size and the performance +of the database. During this time that table will be locked exclusively and can't be accessed otherwise. This means that +the existing history can't be viewed in Icinga Web and new history entries will be buffered in Redis®. + +There is a separate upgrade script `optional/1.2.0-history.sql` to perform the rewrite of the `state_history` table. +This allows you to postpone part of the upgrade to a longer maintenance window in the future, or skip it entirely +if you deem this safe for your installation. + +!!! warning + + Until `optional/1.2.0-history.sql` is applied, you'll have to lower `max_check_attempts` to 255 or less, otherwise + Icinga DB will crash with a database error if hosts/services reach check attempt 256. If you need to lower + `max_check_attempts` but want to keep the same timespan from an outage to a hard state, you can raise + `retry_interval` instead so that `max_check_attempts * retry_interval` stays the same. + +If you apply it, be sure that `1.2.0.sql` was already applied before. Do not interrupt it! At best use tmux/screen not +to lose your SSH session. + +### Unblock History Tables + +!!! info + + You don't need to read this section if you are using PostgreSQL. This applies to MySQL/MariaDB users only. + +In order to fix a loading performance issue of the history view in Icinga DB Web, this upgrade script adds an +appropriate index on the `history` table. Creating this new index normally takes place without blocking any other +queries. However, this may hang for a relatively considerable time, blocking all Icinga DB queries on all`*_history` +tables and the `history` table inclusively if there is an ongoing, long-running query on the `history` table. One way +of causing this to happen is if an Icinga Web user accesses the `icingadb/history` view just before you are running +this script. Depending on how many entries you have in the history table, Icinga DB Web may take quite a long time to +load, until your web servers timeout (if any) kicks in. + +When you observe that the upgrade script has been taking unusually long (`> 60s`) to complete, you can perform the +following analysis on another console and unblock it if necessary. It is important to note though that the script may +need some time to perform the reindexing on the `history` table even if it is not blocked. Nonetheless, you can use the +`show processlist` command to determine whether an excessive number of queries have been stuck in a waiting state. + +``` +MariaDB [icingadb]> show processlist; ++------+-----+-----+----------+-----+------+---------------------------------+------------------------------------+-----+ +| Id | ... | ... | db | ... | Time | State | Info | ... | ++------+-----+-----+----------+-----+------+---------------------------------+------------------------------------+-----+ +| 1475 | ... | ... | icingadb | ... | 1222 | Waiting for table metadata lock | INSERT INTO "notification_history" | ... | +| 1485 | ... | ... | icingadb | ... | 1262 | Creating sort index | SELECT history.id, history.... | ... | +| 1494 | ... | ... | icingadb | ... | 1224 | Waiting for table metadata lock | ALTER TABLE history ADD INDEX ... | ... | +| 1499 | ... | ... | icingadb | ... | 1215 | Waiting for table metadata lock | INSERT INTO "notification_history" | ... | +| 1500 | ... | ... | icingadb | ... | 1215 | Waiting for table metadata lock | INSERT INTO "state_history" ... | ... | +| ... | ... | ... | ... | ... | ... | ... | ... | ... | ++------+-----+-----+----------+-----+------+---------------------------------+------------------------------------+-----+ +``` + +In the above output are way too many Icinga DB queries, including the `ALTER TABLE history ADD INDEX` query from the +upgrade script, waiting for a metadata lock, they are just minimised to the bare essentials. Unfortunately, only one of +these queries is holding the `table metadata lock` that everyone else is now waiting for, which in this case is a +`SELECT` statement initiated by Icinga DB Web in the `icingadb/history` view, which takes an unimaginably long time. +Note that there might be multiple `SELECT` statements started before the upgrade script in your case when the history +view of your Icinga DB Web is opened by different Icinga Web users at the same time. + +You can now either just wait for the `SELECT` statements to finish by themselves and let them block the upgrade script +and all Icinga DB queries on all `*_history` tables or forcibly terminate them and let the remaining queries do their +work. In this case, cancelling that one blocking `SELECT` query will let the upgrade script continue normally without +blocking any other queries. +``` +MariaDB [icingadb]> kill 1485; +``` +In case you are insecure about which Icinga DB Web queries are blocking, you may simply cancel all long-running +`SELECT` statements listed with `show processlist` (see column `Time`). Cancelling a `SELECT` query will neither +crash Icinga DB nor corrupt your database, so feel free to abort every single one of them matching the Icinga DB +database (see column `db`). + ## Upgrading to Icinga DB v1.1.1 Please apply the `1.1.1.sql` upgrade script to your database. @@ -11,7 +103,7 @@ For package installations, you can find this file at `/usr/share/icingadb/schema Note that this upgrade will change the `history` table, which can take some time depending on the size of the table and the performance of the database. While the upgrade is running, that table will be locked and can't be accessed. This -means that the existing history can't be viewed in Icinga Web and new history entries will be buffered in Redis. +means that the existing history can't be viewed in Icinga Web and new history entries will be buffered in Redis®. As the daemon checks the schema version, the recommended way to perform the upgrade is to stop the daemon, apply the schema upgrade and then start the new daemon version. If you want to minimize downtime as much as possible, it is safe @@ -32,20 +124,20 @@ restart the daemon when upgrading the package. ## Upgrading to Icinga DB RC2 -Icinga DB RC2 is a complete rewrite compared to RC1. Because of this, a lot has changed in the Redis and database +Icinga DB RC2 is a complete rewrite compared to RC1. Because of this, a lot has changed in the Redis® and database schema, which is why they have to be deleted and recreated. The configuration file has changed from `icingadb.ini` to `config.yml`. Instead of the INI format, we are now using YAML and have introduced more configuration options. We -have also changed the packages of `icingadb-redis`, which is why the Redis CLI commands are now prefixed with `icingadb` -instead of just `icinga`, i.e. the Redis CLI is now accessed via `icingadb-redis-cli`. +have also changed the packages of `icingadb-redis`, which is why the Redis® CLI commands are now prefixed with `icingadb` +instead of just `icinga`, i.e. the Redis® CLI is now accessed via `icingadb-redis-cli`. Please follow the steps below to upgrade to Icinga DB RC2: 1. Stop Icinga 2 and Icinga DB. -2. Flush your Redis instances using `icinga-redis-cli flushall` (note the `icinga` prefix as we did not +2. Flush your Redis® instances using `icinga-redis-cli flushall` (note the `icinga` prefix as we did not upgrade `icingadb-redis` yet) and stop them afterwards. 3. Upgrade Icinga 2 to version 2.13.2 or newer. 4. Remove the `icinga-redis` package where installed as it may conflict with `icingadb-redis`. -5. Install Icinga DB Redis (`icingadb-redis`) on your primary Icinga 2 nodes to version 6.2.6 or newer. +5. Install Redis® (`icingadb-redis`) on your primary Icinga 2 nodes to version 6.2.6 or newer. 6. Upgrade Icinga DB to RC2. 7. Drop the Icinga DB MySQL database and recreate it using the provided schema. -8. Start Icinga DB Redis, Icinga 2 and Icinga DB. +8. Start Redis®, Icinga 2 and Icinga DB. diff --git a/doc/05-Distributed-Setups.md b/doc/05-Distributed-Setups.md index a324a65..9954e4c 100644 --- a/doc/05-Distributed-Setups.md +++ b/doc/05-Distributed-Setups.md @@ -11,22 +11,22 @@ First, you need an Icinga 2 high availability setup with two master nodes, such [here](https://icinga.com/docs/icinga-2/latest/doc/06-distributed-monitoring#high-availability-master-with-agents). Each of the master nodes must have the Icinga DB feature enabled and -have their own dedicated Redis server set up for it, so that each node writes the monitoring data separately. +have their own dedicated Redis® server set up for it, so that each node writes the monitoring data separately. The setup steps per node are no different from a single node setup and can be found in the [Icinga 2 installation documentation](https://icinga.com/docs/icinga-2/latest/doc/02-installation). -Each Redis server will always have the complete data available as long as -its corresponding Icinga 2 master is running and writing to its Redis. +Each Redis® server will always have the complete data available as long as +its corresponding Icinga 2 master is running and writing to its Redis®. This is because the Icinga 2 master nodes synchronize their data and events with each other as long as they are connected, and each takes over the entire configuration in case the other node or their connection to each other fails. -For each Redis server you need to set up its own dedicated Icinga DB instance that connects to it, +For each Redis® server you need to set up its own dedicated Icinga DB instance that connects to it, but the Icinga DB instances must write to the same database, which of course can be replicated or a cluster. So the steps from the standard [Icinga DB installation documentation](https://icinga.com/docs/icinga-db/latest/doc/02-installation) can be followed. However, as mentioned, the database only needs to be set up once. -All in all, an Icinga DB HA environment involves setting up two Icinga 2 master nodes, two Redis servers, +All in all, an Icinga DB HA environment involves setting up two Icinga 2 master nodes, two Redis® servers, two Icinga DB instances and one database. Please read the note about the [environment ID](#environment-id), @@ -48,9 +48,9 @@ Which Icinga DB instance is responsible is determined by a specific database ope can only be performed by one instance first. In the case of concurrent operations, simply put, only one wins via a locking mechanism. Of course, this is only true if the environment is healthy. -Icinga DB is not trying to be responsible if its corresponding Redis server is unavailable or -Icinga 2 is not writing data to Redis. -If Icinga 2 or Redis become unavailable for more than 60 seconds, +Icinga DB is not trying to be responsible if its corresponding Redis® server is unavailable or +Icinga 2 is not writing data to Redis®. +If Icinga 2 or Redis® become unavailable for more than 60 seconds, Icinga DB releases responsibility so the other instance can take over. ## Multiple Environments diff --git a/doc/TRADEMARKS.md b/doc/TRADEMARKS.md new file mode 100644 index 0000000..952751d --- /dev/null +++ b/doc/TRADEMARKS.md @@ -0,0 +1,13 @@ +# Third-party Trademarks + +All trademarks, logos, and brand names are the property of their respective owners. +Any mention of company, product, or service names in our documentations, product descriptions, +or websites is solely for identification purposes. The use of these names, trademarks, +and brands does not imply endorsement. This document acknowledges trademarks of companies and products, +which are the property of their respective owners, whether registered or unregistered. + +## Redis® + +Redis is a registered trademark of Redis Ltd. Any rights therein are reserved to Redis Ltd. +Any use by Icinga GmbH is for referential purposes only and does not indicate any sponsorship, +endorsement or affiliation between Redis and Icinga GmbH. diff --git a/doc/images/icingadb-architecture.png b/doc/images/icingadb-architecture.png Binary files differindex 3d55ff7..c4af6eb 100644 --- a/doc/images/icingadb-architecture.png +++ b/doc/images/icingadb-architecture.png diff --git a/doc/images/icingadb-daemon.png b/doc/images/icingadb-daemon.png Binary files differindex de3f4c7..1c84152 100644 --- a/doc/images/icingadb-daemon.png +++ b/doc/images/icingadb-daemon.png diff --git a/doc/images/icingadb-database.png b/doc/images/icingadb-database.png Binary files differindex c300095..fc79725 100644 --- a/doc/images/icingadb-database.png +++ b/doc/images/icingadb-database.png diff --git a/doc/images/icingadb-envs.png b/doc/images/icingadb-envs.png Binary files differindex e9938d8..abff442 100644 --- a/doc/images/icingadb-envs.png +++ b/doc/images/icingadb-envs.png diff --git a/doc/images/icingadb-ha.png b/doc/images/icingadb-ha.png Binary files differindex a86b6a0..051689c 100644 --- a/doc/images/icingadb-ha.png +++ b/doc/images/icingadb-ha.png diff --git a/doc/images/icingadb-web.png b/doc/images/icingadb-web.png Binary files differindex 05a3e31..2d98334 100644 --- a/doc/images/icingadb-web.png +++ b/doc/images/icingadb-web.png |
