dremiojs 1.0.0

package/dremiodocs/dremio-software/dremio-software-monitoring.md

@@ -0,0 +1,422 @@
+# Dremio Software - Monitoring
+
+
+
+---
+
+# Source: https://docs.dremio.com/current/admin/monitoring/
+
+Version: current [26.x]
+
+On this page
+
+# Monitoring
+
+As an administrator, you can monitor logs, usage, system telemetry, [jobs](/current/admin/monitoring/jobs/), and [Dremio nodes](/current/admin/monitoring/dremio-nodes).
+
+As the [Dremio Shared Responsibility Models](/responsibility) outline, monitoring is a shared responsibility between Dremio and you. The Shared Responsibility Models lay out Dremio's responsibilities for providing monitoring technologies and logs and your responsibilities for implementation and use.
+
+## Logs
+
+Logs are primarily for troubleshooting issues and monitoring the health of the deployment.
+
+note
+
+By default, Dremio uses the following locations to write logs:
+
+* Tarball - `<DREMIO_HOME>/log`
+* RPM - `/var/log/dremio`
+* Kubernetes - `/opt/dremio/log`
+
+### Log Types
+
+| Log Type | Description |
+| --- | --- |
+| Audit | The `audit.json` file tracks all activities that users perform within Dremio. For details, see [Audit Logging](/current/security/auditing/). |
+| System | The following system logs are enabled by default:  * `access.log`: HTTP access log for the Dremio web server; generated by coordinator nodes only. * `server.gc`: Garbage collection log. * `server.log` and `json/server.json`: Server logs generated in a text format (server.log) and json format (json/server.json). Users granted the `ADMIN` role can disable one of these formats. * `server.out`: Log for Dremio daemon standard out. * `metadata_refresh.log`: Log for refreshing metadata. * `tracker.json`: Tracker log. * `vacuum.json`: Log for the files scanned and deleted by `VACUUM CATALOG` and `VACUUM TABLE` commands. |
+| Query | Query logging is enabled by default. The `queries.json` file contains the log of completed queries; it does not include queries currently in planning or execution. You can retrieve the same information that is in `queries.json` using the [`sys.jobs_recent`](/current/reference/sql/system-tables/jobs_recent) system table. Query logs include the following information:  * `queryId`: Unique ID of the executed query. * `queryText`: SQL query text. * `start`: Start time of the query. * `finish`: End time of the query. * `outcome`: Whether the query was completed or failed. * `username`: User who executed the query. * `commandDescription`: Type of the command; may be a regular SQL query execution job or another SQL command.  The query log may contain additional information depending on your Dremio configuration. |
+| Warning | The `hive.deprecated.function.warning.log` file contains warnings for Hive functions that have been deprecated. To resolve warnings that are listed in this file, replace deprecated functions with a [supported function](/current/reference/sql/sql-functions/ALL_FUNCTIONS/). For example, to resolve a warning that mentions `NVL`, replace `NVL` with `COALESCE`. |
+
+### Retrieving Logs from the Dremio Console Enterprise
+
+Retrieve logs for Kubernetes deployments in the Dremio console at **Settings** > **Support** > **Download Logs**.
+
+#### Prerequisites
+
+* You must be using Dremio 25.1+. Log collection is powered by Dremio Diagnostics Collector (DDC).
+* You must have the EXPORT DIAGNOSTICS privilege to view **Download Logs** options in **Settings** > **Support**.
+
+#### Downloading Logs
+
+To download logs:
+
+1. In the Dremio console, navigate to **Settings** > **Support** > **Download Logs** and click **Start collecting data**.
+
+note
+
+You may store a maximum of three log bundles. Delete log bundles as needed to start a new log collection if you reach the maximum.
+
+We recommend the default `Light` collection, which provides 7 days of logs and completed queries in the `queries.json` file, for troubleshooting most issues. For more complex issues, select the `Standard` collection, which provides 7 days of logs and 28 days of completed queries in the `queries.json` file.
+
+2. When Dremio completes log collection, the log bundle appears in a list below **Start collecting data**. To download a log bundle, click **Download** next to the applicable bundle. Log bundles are available to download for 24 hours.
+
+### Logging in Kubernetes
+
+By default, all logs are written to a persisted volume mounted at `/opt/dremio/log`.
+
+To disable logging, set `writeLogsToFile: false` in the `values-overrides.yaml` configuration file either globally or individually for each `coordinator` and `executor` parent. For more information, see [Configuring Your Values](/current/deploy-dremio/configuring-kubernetes/).
+
+#### Using the Container Console
+
+All logs are written to the container's console (stdout) simultaneously. These logs can be monitored using a `kubectl` command:
+
+Command for viewing logs using kubectl logs
+
+```
+kubectl logs [-f] [container-name]
+```
+
+Use the `-f` flag to continuously print new log entries to your terminal as they are generated.
+
+You can also write logs to a file on disk in addition to stdout. Read [Writing Logs to a File](https://github.com/dremio/dremio-cloud-tools/blob/master/charts/dremio_v2/docs/setup/Writing-Logs-To-A-File.md) for details.
+
+#### Using the AKS Container
+
+Azure provides integration with AKS clusters and Azure Log Analytics to monitor container logs. This is a standard practice that puts infrastructure in place to aggregate logs from containers into a central log store to analyze them.
+
+AKS log monitoring is useful for the following reasons:
+
+* Monitoring logs across lots of pods can be overwhelming.
+* When a pod (for example, a Dremio executor) crashes and restarts, only the logs from the last pod are available.
+* If a pod is crashing regularly, the logs are lost, which makes it difficult to analyze the reasons for the crash.
+
+For more information regarding AKS, see [Azure Monitor features for Kubernetes monitoring](https://learn.microsoft.com/en-us/azure/azure-monitor/containers/container-insights-overview).
+
+#### Enabling Log Monitoring
+
+You can enable log monitoring when creating an AKS cluster or after the cluster has been created.
+
+Once logging is enabled, all your container `stdout` and `stderr` logs are collected by the infrastructure for you to analyze.
+
+1. While creating an AKS cluster, enable container monitoring. You can use an existing Log Analytics workspace or create a new one.
+2. In an existing AKS cluster where monitoring was not enabled during creation, go to **Logs on the AKS cluster** and enable it.
+
+#### Viewing Container Logs
+
+To view all the container logs:
+
+1. Go to **Monitoring** > **Logs**.
+2. Use the filter option to see the logs from the containers that you are interested in.
+
+## Usage
+
+Monitoring usage across your cluster makes it easier to observe patterns, analyze the resources being consumed by your data platform, and understand the impact on your users.
+
+### Catalog Usage Enterprise
+
+Go to **Settings** > **Monitor** to view your catalog usage. You must be a member of the `ADMIN` role to access the Monitor page. When you open the Monitor page, you are directed to the Catalog Usage tab by default where you can see the following metrics:
+
+* Top 10 most queried datasets and how often the jobs on the dataset were accelerated
+* Top 10 most queried spaces and source folders
+
+note
+
+A source can be listed in the top 10 most queried spaces and source folders if the source contains a child dataset that was used in the query (for example, `postgres.accounts`). Queries of datasets in sub-folders (for example, `s3.mybucket.iceberg_table`) are classified by the sub-folder and not the source.
+
+All datasets are assessed in the metrics on the Monitor page except for datasets in the [system tables](/current/reference/sql/system-tables/), the [information schema](https://docs.dremio.com/current/reference/sql/information-schema), and home spaces.
+
+The metrics on the Monitor page analyze only user queries. Refreshes of data Reflections and metadata refreshes are excluded.
+
+### Jobs Enterprise
+
+Go to **Settings** > **Monitor** > **Jobs** to open the Jobs tab. You must be a member of the `ADMIN` role to access the Monitor page. The Jobs tab shows an aggregate view of the following metrics for the jobs that are running on your cluster:
+
+* Total job count over the last 24 hours and the relative rate of failure/cancelation
+* Top 10 most active users based on the number of jobs they ran
+* Total jobs accelerated, total job time saved, and average job speedup from Autonomous Reflections over the past month.
+* Total number of jobs accelerated by autonomous and manual Reflections over time
+* Total number of completed and failed jobs over time
+* Jobs (completed and failed) grouped by the [queue](/current/admin/workloads/workload-management/#default-queues) they ran on
+* Percentage of time that jobs spent in each [state](/current/admin/monitoring/jobs/#job-states-and-statuses)
+* Top 10 longest running jobs
+
+To view all jobs and the details of specific jobs, see [Viewing Jobs](/current/admin/monitoring/jobs/).
+
+### Resources Enterprise
+
+Go to **Settings** > **Monitor** > **Resources** to open the Resources tab. You must be a member of the `ADMIN` role to access the Monitor page. The Resources tab shows an aggregate view of the following metrics for the jobs and nodes running on your cluster:
+
+* Percentage of CPU and memory utilization for each coordinator and executor node
+* Top 10 most CPU and memory intensive jobs
+* Number of running executors
+
+### Cluster Usage
+
+Dremio displays the number of unique users who executed jobs on that day and the number of executed jobs.
+
+1. Hover over ![Icon represents help](/images/icons/help.png "Help icon") in the side navigation bar.
+2. Click **About Dremio** in the menu.
+3. Click the **Cluster Usage Data** tab.
+
+![](/images/cluster-usage.png "Viewing Cluster Usage")
+
+## System Telemetry
+
+Dremio exposes system telemetry metrics in Prometheus format by default. It is not necessary to configure an exporter to collect the metrics. Instead, you can specify the host and port number where metrics are exposed in the [dremio.conf](/current/deploy-dremio/other-options/standalone/dremio-config/dremio-conf/index.md) file and scrape the metrics with any Prometheus-compliant tool.
+
+To specify the host and port number where metrics are exposed, add these two properties to the `dremio.conf` file:
+
+* `services.web-admin.host`: set to the desired host address (typically `0.0.0.0` or the IP address of the host where Dremio is running).
+* `services.web-admin.port`: set to any desired value that is greater than `1024`.
+
+For example:
+
+Example host and port settings in dremio.conf
+
+```
+services.web-admin.host: "127.0.0.1"  
+services.web-admin.port: 9090
+```
+
+Restart Dremio after you update the `dremio.conf` file to make sure your changes take effect.
+
+Access the exported Dremio system telemetry metrics at `http://<yourHost>:<yourPort>/metrics`.
+
+For more information about Prometheus metrics, read [Types of Metrics](https://prometheus.io/docs/tutorials/understanding_metric_types/) in the Prometheus documentation.
+
+Was this page helpful?
+
+[Previous
+
+Workload Management](/current/admin/workloads/workload-management)[Next
+
+Viewing Jobs](/current/admin/monitoring/jobs/)
+
+* Logs
+  + Log Types
+  + Retrieving Logs from the Dremio Console Enterprise
+  + Logging in Kubernetes
+* Usage
+  + Catalog Usage Enterprise
+  + Jobs Enterprise
+  + Resources Enterprise
+  + Cluster Usage
+* System Telemetry
+
+---
+
+# Source: https://docs.dremio.com/current/admin/monitoring/jobs/
+
+Version: current [26.x]
+
+On this page
+
+# Viewing Jobs
+
+All jobs run in Dremio are listed on a separate page, showing the job ID, type, status, and other attributes.
+
+To navigate to the Jobs page, click ![This is the icon that represents the Jobs page.](/images/cloud/jobs-page-icon.png "Jobs icon.") in the side navigation bar.
+
+## Search Filters and Columns
+
+By default, the Jobs page lists the jobs run within the last 30 days and the jobs are filtered by **UI, External Tools** job types. To change these defaults for your account, you can filter on values and manage columns directly on the Jobs page, as shown in this image:
+
+![This is a screenshot showing the main components of the Jobs page.](/images/jobs-ui-map.png "This is a screenshot showing the main components of the Jobs page.")
+
+a. **Search Jobs** by typing the username or job ID.
+
+b. **Start Time** allows you to pick the date and time at which the job began.
+
+c. **Status** represents one or more job states. For descriptions, see Job States and Statuses.
+
+d. **Attribute** includes Accelerator, AI agent, AI function, Downloads, External Tools, Internal, MCP, and UI. For descriptions, see Query Types in the Job Attributes.
+
+e. **User** can be searched by typing the username or checking the box next to the username in the dropdown.
+
+f. **Manage Columns** by checking the boxes next to additional columns that you want to see in the Jobs list. The grayed out checkboxes show the columns that are required by default. You can also rearrange the column order by clicking directly on a column to drag and drop.
+
+## Job Attributes
+
+Each job has the following attributes, which can appear as columns in the list of jobs:
+
+| Attribute | Description |
+| --- | --- |
+| Accelerated | A lightning bolt icon in a row indicates that the job ran a query that was [accelerated](/current/acceleration/). |
+| Dataset | The dataset queried, if one was queried. |
+| Duration | The length of time (in seconds) that a job required from start to completion. |
+| Job ID | A universally unique identifier. |
+| Planner Cost Estimate | A cost estimate calculated by Dremio based on an evaluation of the resources that to be used in the execution of a query. The number is not in units, and is intended to give a an idea of the cost of executing a query relative to the costs of executing other queries. Values are derived by adding weighted estimates of required I/O, memory, and CPU load. In reported values, K = thousand, M = million, B = billion, and T = trillion. For example, a value of 12,543,765,321 is reported as 12.5B. |
+| Planning Time | The length of time (in seconds) in which the query optimizer planned the execution of the query. |
+| Query Type | Represents one of the following query types:  * **UI** - queries issued from the SQL Runner in the Dremio UI. * **External Tools** - queries from client applications, such as Microsoft Power BI, Superset, Tableau, other third-party client applications, and custom applications. * **Accelerator** - queries related to creating, maintaining, and removing Reflections. * **Internal** - queries that Dremio submits for internal operations. * **Downloads** - queries used to download datasets. * **MCP** - queries issued from the Dremio MCP Server. * **AI agent** - queries issued from Dremio's AI Agent. * **AI function** – queries that call AI functions. |
+| Queue | Dremio provides the following generic queues as a starting point for customization:  * High Cost Reflections * High Cost User Queries * Low Cost Reflections * Low Cost User Queries * UI Previews |
+| Rows Returned | Number of output records. |
+| Rows Scanned | Number of input records. |
+| SQL | The SQL query that was submitted for the job. |
+| Start Time | The date and time which the job began. |
+| Status | An icon that represents one or more job states. This column is automatically shown at the start of each row. For descriptions, see [Job states and statuses](.#job-states-and-statuses). |
+| User | Username of the user who ran the query and initiated the job. |
+
+## Job States and Statuses
+
+Each job passes through a sequence of states until it is complete, though the sequence can be interrupted if a query is canceled or if there is an error during a state. In this diagram, the states that a job passes through are in white, and the possible end states are in dark gray.
+
+![](/assets/images/job-states-d8a1b49d0b4cef93a610cd185648e268.png)
+
+This table lists the statuses that the UI lets you filter on and shows how they map to the states:
+
+| Icon | Status | State | Description |
+| --- | --- | --- | --- |
+|  | Setup | Pending | Represents a state where the query is waiting to be scheduled on the query pool. |
+| Metadata Retrieval | Represents a state where metadata schema is retrieved and the SQL command is parsed. |
+| Planning | Represents a state where the following are done:  * Physical and logical planning * Reflection matching * Partition metadata retrieval * Mapping the query to a queue based workload management rules * Pick the engine associated with the query to run the query. |
+|  | Engine Start | Engine Start | Represents a state where the engine starts if it has stopped. If the engine is stopped, it takes time to restart for the executors to be active. If the engine is already started, then this state does not have a duration. |
+|  | Queued | Queued | Represents a state where a job is queued. Each queue has a limit of concurrent queries. If the queries in progress exceed the concurrency limit, the query should wait in the queue until the jobs in progress complete. |
+|  | Running | Execution Planning | Represents a state where executor nodes are selected from the chosen engine to run the query, and work is distributed to each executor. |
+| Running | Represents a state where executor nodes execute and complete the fragments assigned to them. Typically, most queries spend more time in this state. |
+| Starting | Represents a state where the query is starting up. |
+|  | Canceled | Canceled | Represents a terminal state that indicates that the query is canceled by the user or an intervention in the system. |
+|  | Completed | Completed | Represents a terminal state that indicates that the query is successfully completed. |
+|  | Failed | Failed | Represents a terminal state that indicates that the query has failed due to an error. |
+
+Was this page helpful?
+
+[Previous
+
+Monitoring](/current/admin/monitoring/)[Next
+
+Overview](/current/admin/monitoring/jobs/overview)
+
+* Search Filters and Columns
+* Job Attributes
+* Job States and Statuses
+
+---
+
+# Source: https://docs.dremio.com/current/admin/monitoring/dremio-nodes
+
+Version: current [26.x]
+
+On this page
+
+# Monitoring Dremio Nodes
+
+There are various approaches for operational monitoring of Dremio nodes. This topic discusses both:
+
+* Prometheus metrics, which can be leveraged with tools like Grafana to ensure the stability and performance of Dremio deployments.
+* [`queries.json`](/current/admin/monitoring/#log-types), a log file generated by Dremio, which can be used to calculate various service-level agreements (SLAs) related to query performance.
+
+While these two datasets can be used in similar ways, Prometheus metrics are less granular than `queries.json`—the latter allows you to drill down into which specific kinds of queries or users are experiencing SLA breaches.
+
+### Enabling Node Metrics
+
+Dremio enables node monitoring by default. Starting in Dremio 26.0, each node in the cluster exposes Prometheus metrics via the `/metrics` endpoint on port 9010.
+
+### Available Prometheus Metrics
+
+The following table describes the Prometheus metrics provided by Dremio and specifies which Dremio node roles support them:
+
+| Metric Name | Description | Main Coordinator | Scale-out Coordinator | Executor |
+| --- | --- | --- | --- | --- |
+| `jobs_active` | Gauge showing the number of currently active jobs | Yes | Yes | No |
+| `jobs_total` | Counter of total jobs submitted, categorized by the type of query | Yes | Yes | No |
+| `jobs.failed` | Counter of failed jobs categorized by query types | Yes | No | No |
+| `jobs.waiting` | Gauge of currently waiting jobs categorized by queue | Yes | No | No |
+| `dremio.memory.jvm_direct_current` | Total direct memory (in bytes) given to the JVM | Yes | Yes | Yes |
+| `memory.heap.committed` | Committed heap memory as described in [Class MemoryUsage](https://docs.oracle.com/javase/8/docs/api/java/lang/management/MemoryUsage.html) in the Oracle documentation | Yes | Yes | Yes |
+| `memory.heap.init` | Initialized heap memory as described in [Class MemoryUsage](https://docs.oracle.com/javase/8/docs/api/java/lang/management/MemoryUsage.html) in the Oracle documentation | Yes | Yes | Yes |
+| `memory.heap.max` | Maximum amount of heap memory that can be allocated as described in [Class MemoryUsage](https://docs.oracle.com/javase/8/docs/api/java/lang/management/MemoryUsage.html) in the Oracle documentation | Yes | Yes | Yes |
+| `memory.heap.usage` | Ratio of used heap memory to max heap memory, as described in [Class MemoryUsage](https://docs.oracle.com/javase/8/docs/api/java/lang/management/MemoryUsage.html) in the Oracle documentation | Yes | Yes | Yes |
+| `memory.heap.used` | Amount of used heap memory, as described in [Class MemoryUsage](https://docs.oracle.com/javase/8/docs/api/java/lang/management/MemoryUsage.html) in the Oracle documentation | Yes | Yes | Yes |
+| `memory.non-heap.committed` | Amount of non-heap memory committed, as described in [Class MemoryUsage](https://docs.oracle.com/javase/8/docs/api/java/lang/management/MemoryUsage.html) in the Oracle documentation | Yes | Yes | Yes |
+| `memory.non-heap.init` | Initialized non-heap memory as described in [Class MemoryUsage](https://docs.oracle.com/javase/8/docs/api/java/lang/management/MemoryUsage.html) in the Oracle documentation | Yes | Yes | Yes |
+| `memory.non-heap.max` | Maximum amount of non-heap memory that can be allocated, as described in [Class MemoryUsage](https://docs.oracle.com/javase/8/docs/api/java/lang/management/MemoryUsage.html) in the Oracle documentation | Yes | Yes | Yes |
+| `memory.non-heap.usage` | Ratio of used non-heap memory to max non-heap memory, as described in [Class MemoryUsage](https://docs.oracle.com/javase/8/docs/api/java/lang/management/MemoryUsage.html) in the Oracle documentation | Yes | Yes | Yes |
+| `memory.non-heap.used` | Amount of used non-heap memory, as described in [Class MemoryUsage](https://docs.oracle.com/javase/8/docs/api/java/lang/management/MemoryUsage.html) in the Oracle documentation | Yes | Yes | Yes |
+| `memory.total.committed` | Sum of heap and non-heap committed memory (in bytes) | Yes | Yes | Yes |
+| `memory.total.init` | Sum of heap and non-heap initialized memory (in bytes) | Yes | Yes | Yes |
+| `memory.total.max` | Sum of the heap and non-heap max memory (in bytes) | Yes | Yes | Yes |
+| `memory.total.used` | Sum of the heap and non-heap used memory (in bytes) | Yes | Yes | Yes |
+| `reflections.failed` | Scheduled Reflections that have failed and won't be retried | Yes | No | No |
+| `reflections.unknown` | Reflections for which an error occurred in the Reflection manager and that could not be retried | Yes | No | No |
+| `reflections.active` | Currently active Reflections | Yes | No | No |
+| `reflections.refreshing` | Reflections that are currently refreshing or pending a refresh | Yes | No | No |
+| `reflections.manager_sync` | Time taken to run Reflection management | Yes | Yes | No |
+| `threads.blocked.count` | Gauge of currently blocked threads | Yes | Yes | Yes |
+| `threads.count` | Gauge of active and idle threads | Yes | Yes | Yes |
+| `threads.daemon.count` | Number of currently available active daemon threads | Yes | Yes | Yes |
+| `threads.deadlock.count` | Number of currently deadlocked threads | Yes | Yes | Yes |
+| `threads.new.count` | Current number of threads in new state (not yet started) | Yes | Yes | Yes |
+| `threads.runnable.count` | Current number of threads in runnable state (executing) | Yes | Yes | Yes |
+| `threads.terminated.count` | Current number of threads in the terminated state (completed execution) | Yes | Yes | Yes |
+| `threads.timed_waiting.count` | Current number of threads in the timed\_waiting state | Yes | Yes | Yes |
+| `threads.waiting.count` | Current number of threads in the waiting state | Yes | Yes | Yes |
+| `jvm.gc.overhead.percent` | An approximate percentage of CPU time used by garbage collection activities | Yes | Yes | No |
+
+## Parameters to Monitor for Scaling Capacity
+
+The following parameters, derived from the `queries.json`, can help identify when additional engines or vertical scaling are needed to maintain performance.
+
+### Query Execution Errors
+
+By reviewing the `outcomeReason` field in `queries.json`, you can identify resource-related issues and take proactive steps, such as scaling engines or redistributing workloads, to maintain performance and stability.
+
+| Error Type (`outcomeReason`) | Recommended Threshold | Action |
+| --- | --- | --- |
+| `OUT_OF_MEMORY` | 1% of queries running out of direct memory | Add an engine and move workload |
+| `RESOURCE ERROR` | 1% of queries running out of heap memory | Add an engine and move workload |
+| `ExecutionSetupException` | 1% of queries exhibiting node disconnects | Add an engine and move workload |
+| `ChannelClosedException (fabric server)` | 1% of queries exhibiting node disconnects | Add an engine and move workload |
+| `CONNECTION ERROR: Exceeded timeout` | 1% of queries exhibiting node disconnects | Add an engine and move workload |
+
+### Job State Durations
+
+Use the [job state durations](/current/admin/monitoring/jobs/#job-states-and-statuses) (provided in milliseconds) in the `queries.json` to address SLA breaches.
+
+| Job State (`queries.json`) | Recommended Threshold | Action |
+| --- | --- | --- |
+| Total Duration (*finish - start*) | p90 SLA aligns with your needs | Add all the states below |
+| Pending (*pendingTime*) | p90 should not exceed 2000 milliseconds | Vertically scale the main coordinator node |
+| Metadata Retrieval (*metadataRetrievalTime*) | p90 should not exceed 5000 milliseconds | Switch to a table format if the raw data is Parquet |
+| Planning (*planningTime*) | p90 should not exceed 2000 milliseconds | Vertically scale the main coordinator node |
+| Queued (*queuedTime*) | p90 should not exceed 2000 milliseconds | Add an engine and move workload |
+| Execution Planning (*executionPlanningTime*) | p90 should not exceed 2000 milliseconds | Vertically scale the main coordinator node |
+| Starting (*startingTime*) | p90 should not exceed 2000 milliseconds | Add an engine and move workload |
+| Running (*runningTime*) | p90 SLA aligns with your needs | Add an engine and move workload |
+
+*All italicized values can be found in `queries.json` as represented in the parentheses above.*
+
+Was this page helpful?
+
+[Previous
+
+Viewing Jobs](/current/admin/monitoring/jobs/)[Next
+
+Exporting Logs](/current/admin/monitoring/exporting/)
+
+* Enabling Node Metrics
+* Available Prometheus Metrics
+* Parameters to Monitor for Scaling Capacity
+  + Query Execution Errors
+  + Job State Durations
+
+---
+
+# Source: https://docs.dremio.com/current/admin/monitoring/exporting/
+
+Version: current [26.x]
+
+# Exporting Logs
+
+You can use a monitor tool to collect logs from Dremio and forward them to a central location for analysis. See the steps for installing a monitoring tool that can be used to integrate with the following platforms:
+
+* [Amazon S3 and Azure Blob Storage](/current/admin/monitoring/exporting/aws-azure-storage)
+* [Datadog](/current/admin/monitoring/exporting/datadog)
+* [Splunk](/current/admin/monitoring/exporting/splunk)
+
+Was this page helpful?
+
+[Previous
+
+Monitoring Dremio Nodes](/current/admin/monitoring/dremio-nodes)[Next
+
+Amazon S3 and Azure Blob Storage](/current/admin/monitoring/exporting/aws-azure-storage)