> ## Documentation Index > Fetch the complete documentation index at: https://docs.mezmo.com/llms.txt > Use this file to discover all available pages before exploring further. # Summarize pipeline health for one or more pipelines > Returns overall ingestion health as well as pipeline-specific health, such as lag in a pipeline's sources. ## OpenAPI ````yaml /apis/combined-mezmo-api.yaml get /v3/pipeline/health openapi: 3.1.0 info: title: Mezmo API description: >- *REST API for the Mezmo platform: send and export log data, build and manage telemetry pipelines, and administer enterprise accounts.* To use the inline testing functionality here, go into your Mezmo account and add the following address to your CORS Origins page: `https://docs.mezmo.com`. version: 3.0.0 contact: name: Mezmo email: support@mezmo.com url: https://mezmo.com/support servers: - url: https://api.mezmo.com security: - AccessToken: [] tags: - name: Account description: Perform account level actions - name: Alerting description: API to control alerts on pipelines - name: Archiving description: > >*Authentication*: You can find instructions on authentication [here](/log-analysis-api/ref#authentication). The LogDNA Archiving API enables you to programmatically configure your archiving instances via code. Specifically you can set up cold storage buckets to send your logs for long term storage. - name: Board description: > >*Authentication*: You can find instructions on authentication [here](/log-analysis-api/ref#authentication). The LogDNA's API's Board endpoints are used to create, get, list, and delete boards. - name: Configuration description: > >*Authentication*: You can find instructions on authentication [here](/log-analysis-api/ref#authentication). The LogDNA API's Configuration endpoints are used to create, update, and delete views, alerts, and categories. - name: Data Classification & Profiling description: API for classifying and profiling data - name: Edge - Local Deploy description: User routes that are available to use with local Edge instances - name: Enterprise description: Routes for management enterprise level resources - name: Enterprise v1 description: Legacy enterprise management endpoints, superseded by the Enterprise API. - name: Exclusions description: > >*Authentication*: You can find instructions on authentication [here](/log-analysis-api/ref#authentication). Control what you store by creating exclusion rules. New lines that match an exclusion rule will not be stored and will not count toward your storage quota. - name: Export description: > LogDNA provides two endpoints for exporting your log lines. Read the sections below to learn about each, and determine which is appropriate for your use case. ## Export API v1 The Export API v1 is used to export log lines in [JSONL](https://jsonlines.org/) format. Based on your specific plan, the maximum number of logs returned is limited to 10,000 / 20,000. There are two distinct functionalities: 1. Streaming desired log lines directly from the response as raw text data 2. Specifying an email to receive a link that can be used to the download the desired log lines > Note > When an email address is specified, the desired log lines will not be streamed to the response body. > The response will instead send a notification indicating that the request was successful and that the results > will be sent to the email address provided in the request. This entails archiving and uploading the desired logs > to a storage provider. The email includes a URI to download the logs. Be aware that access to this URI will expire > after 24-48 hours. ## Export API v2 The Export API v2 provides an enhancement over v1, allowing you to export any number of log lines using pagination and by-passing the plan-specific limit imposed in v1. By making (multiple) subsequent requests using the `pagination_id` parameter, you can retrieve logs in batches of JSON until all matching log lines have been returned. Each Export API v2 request is limited to 10,000 lines. ### Pagination Functionality Pagination is only necessary when the desired set of log lines is larger than 10,000, since this is the maximum number of results that can be returned in a given page. If an export does not exceed this size, the behavior is similar to v1 -- all of the logs will be returned in a single "page" and no further requests are needed. When an export does exceed this size, refer to the steps outlined below. This is the expected workflow to export a set (cardinality > 10,000) of log lines that requires pagination: 1. Send an initial request with valid query parameters to retrieve logs. Pass a `null` value for the `pagination_id` in the first request. 2. The JSON response contains 2 fields: `lines` and `pagination_id`. The former is an array containing the corresponding batch (the first batch in this case) of logs and the latter is a token used to retrieve the next page of results. 3. Send a subsequent request using the same initial query parameters and also passing in the token received in the response to the `pagination_id` parameter. This will retrieve the next page of results. 4. Repeat this request-response cycle, updating the `pagination_id` parameter with the token returned in every new response, until the response eventually returns a `null` value for the token. This indicates that the corresponding batch of logs is the last and that you have reached the final page. > Important Considerations > In subsequent requests to paginate through results, make sure none of the query parameters & values are modified from the initial request > (excluding `pagination_id`) > The tokens used in the `pagination_id` parameter are tied to a specific export and page so they can be used repeatedly in requests to return > deterministic results > "0" can be passed in to the `from` and `to` parameters which will be resolved to timestamps for a plan's retention boundary and the current > time respectively. This behavior is independent so the value can be passed interchangeably to the parameters -- resulting in 4 possible scenarios: > - [`from`: \, `to`: \] > - [`from`: 0 (retention boundary), `to`: \] > - [`from`: \, `to`: 0 (current time)] > - [`from`: 0 (retention boundary), `to`: 0 (current time)] - name: Groups description: >- Manage log groups that scope which data is accessible to members in that group. - name: Incident Mode description: Change or read state of pipeline (incident mode on/off) - name: Index Rate Alert description: Configure alerts that fire when the log index rate crosses a threshold. - name: Ingestion description: Ingestion API - name: Keys description: Create and manage ingestion and service keys for an account. - name: Log Volume Reduction description: CRUD operations for log volume reduction - name: Members description: Manage organization members, their roles, and RBAC group assignments. - name: Metrics description: Usage metrics for pipelines - name: Parsing Template description: Manage custom log parsing templates. - name: Pipeline Export description: Export pipeline to terraform - name: Pipeline Management description: CRUD Operations for pipeline - name: Pipeline Nodes description: CRUD operations for sources, processors, and destinations - name: Processor Groups description: CRUD operations for Processor Groups - name: Sampling and Simulation description: >- Create samples of data and run them through a simulated pipeline without affecting your published pipeline - name: Screens description: Create and manage custom UI layouts for display on large format screens. - name: Shared Sources description: Create and manage sources for use across multiple pipelines - name: Suspensions description: > >*Authentication*: You can find instructions on authentication [here](/log-analysis-api/ref#authentication). The LogDNA Start/Stop Ingestion API allows users to programmatically manage their data ingestion status. Users can get the current status of their ingestion, suspend their ingestion, and resume their ingestion. To prevent an accidental API call, the suspension of ingestion requires two subsequent API calls. > You can find instructions on authentication [here](/log-analysis-api/ref#authentication). - name: Usage v1 description: > >*Authentication*: You can find instructions on authentication [here](/log-analysis-api/ref#authentication). The Usage API provides endpoints for retrieving aggregated usage information for applications, hosts and tags during a time period. While the `to` and `from` times are unix timestamps, the report is granular by day. Therefore only the day portion is used to establish a date range. ### How is **Usage** defined? This API defines usage as a percentage of the total number of lines ingested by the account within the defined period of time. For example, an app called `myapp` that returns a percentage of `15` in the response object has 15 percent of their logs coming from `myapp`. - name: Usage v2 description: > >*Authentication*: You can find instructions on authentication [here](/log-analysis-api/ref#authentication). The Usage API provides endpoints for retrieving aggregated usage information for applications, hosts and tags during a time period. While the `to` and `from` times are unix timestamps, the report is granular by day. Therefore only the day portion is used to establish a date range. ### How is **Usage** defined? This API defines usage as the number of bytes used by the log lines stored on disk by the account within the defined period of time. For example, an app called `myapp` that returns `150,000` total bytes in the response object indicates that `myapp` is consuming `150,000` bytes of disk storage over the time range. externalDocs: url: https://docs.mezmo.com paths: /v3/pipeline/health: get: tags: - Pipeline Management summary: Summarize pipeline health for one or more pipelines description: >- Returns overall ingestion health as well as pipeline-specific health, such as lag in a pipeline's sources. parameters: - schema: type: integer minimum: 1 maximum: 60 default: 15 in: query name: interval_minutes required: false description: The window interval for measuring ingestion volume - schema: type: array items: type: string format: uuid description: A pipeline id in: query name: pipeline_ids required: false description: Return only pipelines with the given IDs responses: '200': description: Default Response content: application/json: schema: type: object properties: meta: type: object additionalProperties: true data: type: object description: Overall health of data ingestion and pipeline sources properties: interval_minutes: type: integer description: The window interval for measuring ingestion volume ingestion_health: type: object properties: ingestion_metrics_status: type: string description: >- A success or failure message for the ability to fetch metrics related to ingestion routes routes: type: array description: Ingestion status code health metrics per route items: type: object properties: route: type: string description: The route path health: type: array description: >- The health of a specific route measured by changes in status code items: type: object properties: status_code: type: integer description: The HTTP status code change_percent: type: number description: >- The percentage change for the status code over time. The result is a comparison of the current interval and the same interval offset by `interval_minutes` ago. For example, when `{interval_minutes: 5, offset_minutes: 5}`, that calculates the percentage change in a 5-minute window from 5 minutes ago to a 5-minute window 10 minutes ago. pipeline_health: type: object properties: lag_metrics_status: type: string description: >- A success or failure message for the ability to fetch lag metrics pipelines: type: array description: >- All active and published pipelines. Inactive or unpublished pipelines are not included. items: type: object properties: id: type: string format: uuid description: The pipeline id title: type: string description: The pipeline title published_at: type: string format: date-time description: >- The date/time of the pipeline's last publish (if at all) sources: type: array description: Sources associated with this pipeline items: type: object properties: id: type: string description: >- The source id, which can also be the consumer group id type: type: string description: The type of source component title: type: string description: The title of the source component is_consumer_group: type: boolean description: >- Whether this source is a consumer group that could have lag lag_event_count: anyOf: - type: number description: >- A relative measure of how far this source is falling behind in processing. A higher value indicates the source is further behind, and a value of `0` indicates it is caught up. Use this as a directional signal, not an exact count of individual events. If this value is `null`, then it could mean the source has never had consumers, or that the lag metrics were unavailable (check `lag_metrics_status`). - type: 'null' components: securitySchemes: AccessToken: type: apiKey in: header name: Authorization description: >- The primary authentication method for the Mezmo API. Pass the key in the `Authorization` header in the format `Token `. For example: ``` curl -H 'Authorization: Token ' ``` This key is used for all APIs with the exception of ingest. ````