@cryptotaxi247 / netdata-1 / commits / 3e79a5a8c

Regenerate integrations docs (#21297)

Co-authored-by: ilyam8 <22274335+ilyam8@users.noreply.github.com>

Netdata bot committed Nov 17, 2025 at 12:57 UTC 3e79a5a8ca5cc8f846f67c95e2fa09620827d8cd
4 files changed +648 -1
src/collectors/COLLECTORS.md
+1
@@ -216,6 +216,7 @@ Need a dedicated integration? [Submit a feature request](https://github.com/netd
216 | [RethinkDB](https://github.com/netdata/netdata/blob/master/src/go/plugin/go.d/collector/rethinkdb/integrations/rethinkdb.md) | It collects cluster-wide metrics such as server status, client connections, active clients, query rate, and document read/write rates. |
217 | [Riak KV](https://github.com/netdata/netdata/blob/master/src/go/plugin/go.d/collector/riakkv/integrations/riak_kv.md) | This collector monitors RiakKV metrics about throughput, latency, resources and more. |
218 | [SQL Database agnostic](https://github.com/netdata/netdata/blob/master/src/go/plugin/go.d/collector/prometheus/integrations/sql_database_agnostic.md) | Query SQL databases for efficient database performance monitoring. |
219 +| [SQL databases (generic)](https://github.com/netdata/netdata/blob/master/src/go/plugin/go.d/collector/sql/integrations/sql_databases_generic.md) | Metrics and charts for this collector are **entirely defined by your SQL configuration**. |
220 | [Vertica](https://github.com/netdata/netdata/blob/master/src/go/plugin/go.d/collector/prometheus/integrations/vertica.md) | Monitor Vertica analytics database platform metrics for efficient database performance and management. |
221 | [Warp10](https://github.com/netdata/netdata/blob/master/src/go/plugin/go.d/collector/prometheus/integrations/warp10.md) | Monitor Warp 10 time-series database metrics for efficient time-series data management and performance. |
222 | [YugabyteDB](https://github.com/netdata/netdata/blob/master/src/go/plugin/go.d/collector/yugabytedb/integrations/yugabytedb.md) | This collector monitors the activity and performance of YugabyteDB servers. |
src/collectors/windows.plugin/integrations/sensors.md
+12 -1
@@ -89,6 +89,7 @@ Metrics:
89 | system.hw.sensor.distance.input | inputX, inputY, inputZ | m |
90 | system.hw.sensor.acceleration.input | inputX, inputY, inputZ | g |
91 | system.hw.sensor.state.input | ready, not_available, no_data, initializing, access_denied, error | status |
92 +| system.hw.sensor.custom | inputN | nd |
93
94
95
@@ -143,6 +144,16 @@ sudo ./edit-config netdata.conf
144 ```
145
146 ##### Examples
146 -There are no configuration examples.
147
148 +###### Specific Sensors
149 +
150 +You can add custom sensor information by creating a dedicated sensor section.
151 +
152 +```yaml
153 +[plugin:windows:GetSensors:Your Sensor Name]
154 + units = Speed
155 + multiplier = 100
156 + title = Current speed.
157 +
158 +```
159
src/go/plugin/go.d/collector/sql/README.md new
+1
@@ -0,0 +1 @@
1 +integrations/sql_databases_generic.md
\ No newline at end of file
src/go/plugin/go.d/collector/sql/integrations/sql_databases_generic.md new
+634
@@ -0,0 +1,634 @@
1 +<!--startmeta
2 +custom_edit_url: "https://github.com/netdata/netdata/edit/master/src/go/plugin/go.d/collector/sql/README.md"
3 +meta_yaml: "https://github.com/netdata/netdata/edit/master/src/go/plugin/go.d/collector/sql/metadata.yaml"
4 +sidebar_label: "SQL databases (generic)"
5 +learn_status: "Published"
6 +learn_rel_path: "Collecting Metrics/Databases"
7 +most_popular: False
8 +message: "DO NOT EDIT THIS FILE DIRECTLY, IT IS GENERATED BY THE COLLECTOR'S metadata.yaml FILE"
9 +endmeta-->
10 +
11 +# SQL databases (generic)
12 +
13 +
14 +<img src="https://netdata.cloud/img/sql.svg" width="150"/>
15 +
16 +
17 +Plugin: go.d.plugin
18 +Module: sql
19 +
20 +<img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" />
21 +
22 +## Overview
23 +
24 +Metrics and charts for this collector are **entirely defined by your SQL
25 +configuration**. There is no fixed metric reference: each job can expose
26 +different metrics depending on its `metrics` and `queries` blocks.
27 +
28 +To see what a specific job collects, open that job’s dashboard in Netdata
29 +and inspect the charts and dimensions it created.
30 +
31 +:::tip
32 +
33 +To change what is collected, edit the `metrics` (and optional `queries`)
34 +in the job configuration. After you save the changes, the updated set of
35 +charts and metrics is reflected in Netdata after the next data collection.
36 +
37 +:::
38 +
39 +
40 +The collector connects to your database using Go’s **database/sql** package
41 +and the selected driver:
42 +
43 + - `mysql` — MySQL / MariaDB
44 + - `pgx` — PostgreSQL
45 + - `oracle` — Oracle Database
46 + - `sqlserver` — Microsoft SQL Server / Azure SQL
47 +
48 +For each metric block you define, it executes the SQL query (inline or via
49 +`query_ref`), reads the result set, and maps it to Netdata charts and
50 +dimensions.
51 +
52 +### Result Processing Modes
53 +
54 +| Mode | How it works | Best used when |
55 +|------------|------------------------------------------------------------------------------|-----------------------------------------------------|
56 +| **columns**| Specific numeric columns from each row become dimensions on your charts. | The result set has stable, known column names. |
57 +| **kv** | One column provides metric names (keys) and another provides their values. | The set of metrics is dynamic or key–value shaped. |
58 +
59 +
60 +This collector is supported on all platforms.
61 +
62 +This collector supports collecting metrics from multiple instances of this integration, including remote instances.
63 +
64 +
65 +### Default Behavior
66 +
67 +#### Auto-Detection
68 +
69 +This is a **generic collector** and does **not** perform automatic detection.
70 +
71 +It does not create any jobs on its own — you must configure at least one
72 +job before it can collect data.
73 +
74 +
75 +#### Limits
76 +
77 +There are no built-in limits on the number of queries or rows processed.
78 +However, each metric block must define at least one chart, and each chart
79 +must define at least one dimension.
80 +
81 +Keep your queries lightweight and scoped to the data you actually need
82 +to avoid adding load on the database server.
83 +
84 +
85 +#### Performance Impact
86 +
87 +Performance impact depends entirely on the queries you configure and the
88 +collection frequency (update_every).
89 +
90 +Prefer indexed reads, avoid full table scans or heavy aggregations, and
91 +consider using database views tailored for monitoring.
92 +
93 +
94 +## Metrics
95 +
96 +Metrics and charts are **defined by your SQL queries and metric blocks** at runtime. They differ by database engine, schema, and configuration, and may include, for example, connection counts, cache hit ratios, row throughput, lock statistics, or custom business KPIs. Use the **Metrics** tab on the job’s dashboard to see exactly what is collected for that job.
97 +
98 +:::tip
99 +
100 + To change what is collected, edit the `metrics` (and optionally `queries`) sections in `go.d/sql.conf` for the corresponding job. Each change is reflected in Netdata charts after the next data collection.
101 +
102 +:::
103 +
104 +
105 +
106 +## Alerts
107 +
108 +There are no alerts configured by default for this integration.
109 +
110 +
111 +## Setup
112 +
113 +
114 +You can configure the **sql** collector in two ways:
115 +
116 +| Method | Best for | How to |
117 +|-----------------------|------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------|
118 +| [**UI**](#via-ui) | Fast setup without editing files | Go to **Nodes → Configure this node → Collectors → Jobs**, search for **sql**, then click **+** to add a job. |
119 +| [**File**](#via-file) | If you prefer configuring via file, or need to automate deployments (e.g., with Ansible) | Edit `go.d/sql.conf` and add a job. |
120 +
121 +:::important
122 +
123 +UI configuration requires paid Netdata Cloud plan.
124 +
125 +:::
126 +
127 +
128 +### Prerequisites
129 +
130 +#### Create a read-only database user
131 +
132 +Create a dedicated user for Netdata with read-only privileges on the
133 +views/tables used in your monitoring queries.
134 +
135 +For example, on a typical RDBMS you would:
136 +
137 +- Create a user.
138 +- Grant SELECT on system metrics views or monitoring views.
139 +
140 +After creating the user and updating the configuration, restart the
141 +Netdata Agent with `sudo systemctl restart netdata`, or the appropriate
142 +method for your system.
143 +
144 +
145 +#### Allow Netdata to connect to the database
146 +
147 +Ensure the Netdata host can reach the database via the configured DSN,
148 +either using:
149 +
150 +- a local UNIX/TCP socket, or
151 +- a network connection (hostname/IP and port).
152 +
153 +If the database is remote, make sure any firewalls or security groups
154 +allow connections from the Netdata node.
155 +
156 +
157 +
158 +### Configuration
159 +
160 +#### Options
161 +
162 +**Full Configuration Structure**
163 +
164 +```yaml
165 +# ---------- CONNECTION ----------
166 +driver: <mysql|pgx|oracle|sqlserver> # REQUIRED. SQL driver.
167 +dsn: "<connection string>" # REQUIRED. Driver-specific DSN/URL.
168 +
169 +# Optional connection settings
170 +timeout: <seconds> # OPTIONAL. Query timeout.
171 +
172 +# Optional static labels applied to all charts
173 +static_labels:
174 + <label_key1>: <label_value>
175 + <label_key2>: <label_value>
176 +
177 +# ---------- REUSABLE QUERIES ----------
178 +# Optional. Define reusable SQL queries referenced later via query_ref.
179 +queries:
180 + - id: <query_id>
181 + query: |
182 + SELECT ...
183 +
184 +# ---------- METRICS ----------
185 +# Each metric block runs one query and generates one or more charts.
186 +metrics:
187 + - id: <metric_block_id> # REQUIRED. Unique within this job.
188 +
189 + # Choose ONE of these:
190 + query_ref: <query_id> # Use a reusable query
191 + # OR
192 + # query: | # Inline SQL
193 + # SELECT ...
194 +
195 + mode: <columns|kv> # REQUIRED. How to interpret result rows.
196 +
197 + # KV mode settings (only when mode: kv)
198 + kv_mode:
199 + name_col: <column_name> # Column containing keys
200 + value_col: <column_name> # Column containing numeric values
201 +
202 + # Optional: derive labels from row columns (creates per-label charts)
203 + labels_from_row:
204 + - source: <column_name> # Column name from result set
205 + name: <label_key> # Label key exposed to Netdata
206 + - source: <column_name>
207 + name: <label_key>
208 +
209 + # Charts produced by this metric block
210 + charts:
211 + - title: "<Chart Title>" # REQUIRED. Shown in dashboards.
212 + context: "<context.name>" # REQUIRED. Netdata context.
213 + family: "<family>" # REQUIRED. Netdata chart family.
214 + units: "<units>" # REQUIRED. Unit string for the chart.
215 + type: <line|stacked|area> # OPTIONAL. Default: line.
216 + algorithm: <absolute|incremental> # OPTIONAL. Default: absolute.
217 +
218 + dims:
219 + # ---- COLUMNS MODE DIM ----
220 + # In mode: columns, `source` MUST be a numeric COLUMN name from the result set.
221 + - name: <dim_id> # REQUIRED. Dimension id (unique within this chart).
222 + source: <column_name> # REQUIRED. Numeric column to chart.
223 +
224 + # ---- KV MODE DIM ----
225 + # In mode: kv, `source` MUST be a KEY name (NOT a column).
226 + # The collector finds the row where (row[kv_mode.name_col] == `source`)
227 + # and uses row[kv_mode.value_col].
228 + - name: <dim_id>
229 + source: <key_name> # REQUIRED. Key name resolved via kv_mode.name_col.
230 +
231 + # ---- STATUS DIM (one-hot 1/0) ----
232 + # Works in BOTH modes. Evaluates `status_when` against the resolved value:
233 + # * columns mode: the value in the specified column for the row
234 + # * kv mode: the value for the resolved key (row[kv_mode.value_col])
235 + - name: <dim_id>
236 + source: <column_name_or_key_name> # Same interpretation as above, per mode.
237 + status_when: # Exactly ONE of the following:
238 + equals: <string|number|bool> # Active (1) if value == this literal.
239 + # in: [ <v1>, <v2>, ... ] # Active if value is in the list.
240 + # match: '^regex$' # Active if value matches this regex.
241 +```
242 +
243 +
244 +<details open><summary>Config options</summary>
245 +
246 +
247 +
248 +| Group | Option | Description | Default | Required |
249 +|:------|:-----|:------------|:--------|:---------:|
250 +| **Collection** | update_every | Data collection interval (seconds). | 1 | no |
251 +| | autodetection_retry | Autodetection retry interval (seconds). Not used for this collector. Set 0 to disable. | 0 | no |
252 +| **Target** | driver | SQL driver to use. Supported values: `mysql`, `pgx`, `oracle`, `sqlserver`. | mysql | yes |
253 +| | dsn | Database connection string (DSN). The format depends on the selected driver ( ([MySQL](https://github.com/go-sql-driver/mysql#dsn-data-source-name), [PostgreSQL](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING-URIS), [MS SQL Server](https://github.com/denisenkom/go-mssqldb#connection-parameters-and-dsn)). | | yes |
254 +| **Connection** | timeout | Query and connection check timeout (seconds). | 5 | no |
255 +| **Labels** | static_labels | A map of static labels added to every chart created by this job. Useful for tagging charts with environment, region, or role. | {} | no |
256 +| **Queries & Metrics** | queries | A list of reusable queries. Metric blocks can reference these via `query_ref` to avoid repeating SQL. See [Configuration Structure](#configuration) for details. | [] | no |
257 +| | metrics | A list of metric blocks. Each block defines how a query is executed and how its result is transformed into one or more charts. See [Configuration Structure](#configuration) for details. | [] | yes |
258 +| **Virtual Node** | vnode | Associates this data collection job with a Virtual Node. | | no |
259 +
260 +
261 +</details>
262 +
263 +
264 +#### via UI
265 +
266 +Configure the **sql** collector from the Netdata web interface:
267 +
268 +1. Go to **Nodes**.
269 +2. Select the node **where you want the sql data-collection job to run** and click the :gear: (**Configure this node**). That node will run the data collection.
270 +3. The **Collectors → Jobs** view opens by default.
271 +4. In the Search box, type _sql_ (or scroll the list) to locate the **sql** collector.
272 +5. Click the **+** next to the **sql** collector to add a new job.
273 +6. Fill in the job fields, then click **Test** to verify the configuration and **Submit** to save.
274 + - **Test** runs the job with the provided settings and shows whether data can be collected.
275 + - If it fails, an error message appears with details (for example, connection refused, timeout, or command execution errors), so you can adjust and retest.
276 +
277 +
278 +#### via File
279 +
280 +The configuration file name for this integration is `go.d/sql.conf`.
281 +
282 +The file format is YAML. Generally, the structure is:
283 +
284 +```yaml
285 +update_every: 1
286 +autodetection_retry: 0
287 +jobs:
288 + - name: some_name1
289 + - name: some_name2
290 +```
291 +You can edit the configuration file using the [`edit-config`](https://github.com/netdata/netdata/blob/master/docs/netdata-agent/configuration/README.md#edit-a-configuration-file-using-edit-config) script from the
292 +Netdata [config directory](https://github.com/netdata/netdata/blob/master/docs/netdata-agent/configuration/README.md#the-netdata-config-directory).
293 +
294 +```bash
295 +cd /etc/netdata 2>/dev/null || cd /opt/netdata/etc/netdata
296 +sudo ./edit-config go.d/sql.conf
297 +```
298 +
299 +##### Examples
300 +
301 +###### Columns mode – per-database conflicts (with labels)
302 +
303 +PostgreSQL example that collects database-level conflict counters from
304 +`pg_stat_database_conflicts` and creates a separate chart instance per
305 +database using `labels_from_row`.
306 +
307 +The query:
308 +
309 +```sql
310 +SELECT
311 + datname,
312 + confl_tablespace,
313 + confl_lock,
314 + confl_snapshot,
315 + confl_bufferpin,
316 + confl_deadlock
317 +FROM pg_stat_database_conflicts;
318 +```
319 +
320 +Example output:
321 +
322 +| datname | confl_tablespace | confl_lock | confl_snapshot | confl_bufferpin | confl_deadlock |
323 +|------------|------------------|------------|----------------|-----------------|----------------|
324 +| postgres | 0 | 0 | 0 | 0 | 0 |
325 +| production | 0 | 0 | 0 | 0 | 0 |
326 +
327 +This configuration turns each row into a **chart instance** (one for
328 +`db=postgres`, one for `db=production`) with five dimensions
329 +(`confl_tablespace`, `confl_lock`, `confl_snapshot`, `confl_bufferpin`,
330 +`confl_deadlock`).
331 +
332 +
333 +<details open><summary>Config</summary>
334 +
335 +```yaml
336 +jobs:
337 + - name: pg_conflicts_per_db
338 + driver: pgx
339 + dsn: 'postgresql://netdata:password@127.0.0.1:5432/postgres'
340 + timeout: 5
341 +
342 + metrics:
343 + - id: conflicts
344 + mode: columns
345 + query: |
346 + SELECT
347 + datname,
348 + confl_tablespace,
349 + confl_lock,
350 + confl_snapshot,
351 + confl_bufferpin,
352 + confl_deadlock
353 + FROM pg_stat_database_conflicts;
354 + labels_from_row:
355 + - source: datname
356 + name: db
357 + charts:
358 + - title: "PostgreSQL conflicts"
359 + context: sql.pg_conflicts
360 + family: conflicts
361 + units: conflicts
362 + type: line
363 + algorithm: absolute
364 + dims:
365 + - name: confl_tablespace
366 + source: confl_tablespace
367 + - name: confl_lock
368 + source: confl_lock
369 + - name: confl_snapshot
370 + source: confl_snapshot
371 + - name: confl_bufferpin
372 + source: confl_bufferpin
373 + - name: confl_deadlock
374 + source: confl_deadlock
375 +
376 +```
377 +</details>
378 +
379 +###### Columns mode – single numeric value (uptime)
380 +
381 +PostgreSQL example that exposes a single numeric metric (server uptime in
382 +seconds) as a one-dimension chart using columns mode.
383 +
384 +The query:
385 +
386 +```sql
387 +SELECT
388 + EXTRACT(
389 + EPOCH FROM (now() - pg_postmaster_start_time())
390 + ) AS uptime_seconds;
391 +```
392 +
393 +Example output:
394 +
395 +| uptime_seconds |
396 +|----------------|
397 +| 50.867359 |
398 +
399 +This configuration maps the `uptime_seconds` column to a single
400 +`uptime` dimension on the `sql.pg_uptime` chart.
401 +
402 +
403 +<details open><summary>Config</summary>
404 +
405 +```yaml
406 +jobs:
407 + - name: pg_uptime
408 + driver: pgx
409 + dsn: 'postgresql://netdata:password@127.0.0.1:5432/postgres'
410 + timeout: 5
411 +
412 + metrics:
413 + - id: uptime
414 + mode: columns
415 + query: |
416 + SELECT
417 + EXTRACT(
418 + EPOCH FROM (now() - pg_postmaster_start_time())
419 + ) AS uptime_seconds;
420 + charts:
421 + - title: "PostgreSQL uptime"
422 + context: sql.pg_uptime
423 + family: uptime
424 + units: seconds
425 + type: line
426 + algorithm: absolute
427 + dims:
428 + - name: uptime
429 + source: uptime_seconds
430 +
431 +```
432 +</details>
433 +
434 +###### KV mode – connection states as key/value pairs
435 +
436 +PostgreSQL example that aggregates connection states from
437 +`pg_stat_activity` and uses kv mode to map each state to a dimension.
438 +
439 +The query:
440 +
441 +```sql
442 +SELECT
443 + state,
444 + count(*) AS cnt
445 +FROM pg_stat_activity
446 +GROUP BY state;
447 +```
448 +
449 +Example output:
450 +
451 +| state | cnt |
452 +|------------------------------|-----|
453 +| active | 1 |
454 +| idle | 14 |
455 +| idle in transaction | 7 |
456 +| idle in transaction (aborted)| 1 |
457 +| fastpath function call | 1 |
458 +| disabled | 1 |
459 +
460 +With `mode: kv`, `state` becomes the **key** and `cnt` the **value**.
461 +Each distinct `state` value is mapped to a chart dimension via `dims[*].source`.
462 +
463 +
464 +<details open><summary>Config</summary>
465 +
466 +```yaml
467 +jobs:
468 + - name: pg_activity_states
469 + driver: pgx
470 + dsn: 'postgresql://netdata:password@127.0.0.1:5432/postgres'
471 + timeout: 5
472 +
473 + metrics:
474 + - id: activity_states
475 + mode: kv
476 + query: |
477 + SELECT
478 + state,
479 + count(*) AS cnt
480 + FROM pg_stat_activity
481 + GROUP BY state;
482 + kv_mode:
483 + name_col: state
484 + value_col: cnt
485 + charts:
486 + - title: "PostgreSQL connection states"
487 + context: sql.pg_activity_states
488 + family: connections
489 + units: connections
490 + type: stacked
491 + algorithm: absolute
492 + dims:
493 + - name: active
494 + source: active
495 + - name: idle
496 + source: idle
497 + - name: idle_in_transaction
498 + source: "idle in transaction"
499 + - name: idle_in_transaction_aborted
500 + source: "idle in transaction (aborted)"
501 + - name: fastpath_function_call
502 + source: "fastpath function call"
503 + - name: disabled
504 + source: disabled
505 +
506 +```
507 +</details>
508 +
509 +###### Columns mode – map state values to a status metric
510 +
511 +Simple PostgreSQL example that turns a boolean-like state into a 0/1
512 +status metric using `status_when`.
513 +
514 +The query:
515 +
516 +```sql
517 +SELECT pg_is_in_recovery();
518 +```
519 +
520 +Example output:
521 +
522 +| pg_is_in_recovery |
523 +|-------------------|
524 +| f |
525 +
526 +This configuration creates a single chart with two status dimensions:
527 + - `in_recovery` becomes **1 when the value is `"t"`** and **0 otherwise**.
528 + - `not_in_recovery` becomes **1 when the value is `"f"`** and **0 otherwise**.
529 +
530 +
531 +<details open><summary>Config</summary>
532 +
533 +```yaml
534 +jobs:
535 + - name: pg_recovery_status
536 + driver: pgx
537 + dsn: 'postgresql://netdata:password@127.0.0.1:5432/postgres'
538 + timeout: 5
539 +
540 + metrics:
541 + - id: recovery_status
542 + mode: columns
543 + query: |
544 + SELECT pg_is_in_recovery();
545 + charts:
546 + - title: "PostgreSQL recovery status"
547 + context: sql.pg_recovery_status
548 + family: state
549 + units: status
550 + type: line
551 + algorithm: absolute
552 + dims:
553 + - name: in_recovery
554 + source: pg_is_in_recovery
555 + status_when:
556 + equals: "t"
557 + - name: not_in_recovery
558 + source: pg_is_in_recovery
559 + status_when:
560 + equals: "f"
561 +
562 +```
563 +</details>
564 +
565 +
566 +
567 +## Troubleshooting
568 +
569 +### Debug Mode
570 +
571 +**Important**: Debug mode is not supported for data collection jobs created via the UI using the Dyncfg feature.
572 +
573 +To troubleshoot issues with the `sql` collector, run the `go.d.plugin` with the debug option enabled. The output
574 +should give you clues as to why the collector isn't working.
575 +
576 +- Navigate to the `plugins.d` directory, usually at `/usr/libexec/netdata/plugins.d/`. If that's not the case on
577 + your system, open `netdata.conf` and look for the `plugins` setting under `[directories]`.
578 +
579 + ```bash
580 + cd /usr/libexec/netdata/plugins.d/
581 + ```
582 +
583 +- Switch to the `netdata` user.
584 +
585 + ```bash
586 + sudo -u netdata -s
587 + ```
588 +
589 +- Run the `go.d.plugin` to debug the collector:
590 +
591 + ```bash
592 + ./go.d.plugin -d -m sql
593 + ```
594 +
595 + To debug a specific job:
596 +
597 + ```bash
598 + ./go.d.plugin -d -m sql -j jobName
599 + ```
600 +
601 +### Getting Logs
602 +
603 +If you're encountering problems with the `sql` collector, follow these steps to retrieve logs and identify potential issues:
604 +
605 +- **Run the command** specific to your system (systemd, non-systemd, or Docker container).
606 +- **Examine the output** for any warnings or error messages that might indicate issues. These messages should provide clues about the root cause of the problem.
607 +
608 +#### System with systemd
609 +
610 +Use the following command to view logs generated since the last Netdata service restart:
611 +
612 +```bash
613 +journalctl _SYSTEMD_INVOCATION_ID="$(systemctl show --value --property=InvocationID netdata)" --namespace=netdata --grep sql
614 +```
615 +
616 +#### System without systemd
617 +
618 +Locate the collector log file, typically at `/var/log/netdata/collector.log`, and use `grep` to filter for collector's name:
619 +
620 +```bash
621 +grep sql /var/log/netdata/collector.log
622 +```
623 +
624 +**Note**: This method shows logs from all restarts. Focus on the **latest entries** for troubleshooting current issues.
625 +
626 +#### Docker Container
627 +
628 +If your Netdata runs in a Docker container named "netdata" (replace if different), use this command:
629 +
630 +```bash
631 +docker logs netdata 2>&1 | grep sql
632 +```
633 +
634 +