> ## 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. # Export log lines > Use this method to export logs in JSON format from a logging instance. ## OpenAPI ````yaml /log-analysis.json get /v2/export openapi: 3.0.1 info: title: Log Analysis API description: > *REST API to send log data, export data and manage configuration* To utilize the inline testing functionality here, please go into your Mezmo account and add the following address to your CORS Origins page: `https://docs.mezmo.com`. version: '2.1' servers: - url: https://api.mezmo.com security: - AccessToken: [] - servicekeyAuth: [] - ibmIamAuth: [] tags: - 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: 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: Ingestion description: Ingestion 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: 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. paths: /v2/export: get: tags: - Export summary: Export log lines description: Use this method to export logs in JSON format from a logging instance. operationId: exportv2 parameters: - name: from in: query description: >- Start time (inclusive). Set as UNIX timestamp in seconds or milliseconds. required: true schema: type: string - name: to in: query description: >- End time (inclusive). Set as UNIX timestamp in seconds or milliseconds. required: true schema: type: string - name: size in: query description: Number of log lines to include in the export. schema: type: string - name: hosts in: query description: Comma-separated list of hosts. schema: type: string - name: apps in: query description: Comma-separated list of applications. schema: type: string - name: levels in: query description: Comma-separated list of log levels. schema: type: string - name: query in: query description: Search query. schema: type: string - name: prefer in: query description: >- Defines the log lines that you want to export. Valid values are head, first log lines, and tail, last log lines. If not specified, defaults to tail. schema: type: string - name: pagination_id in: query description: >- ID that indicates which page of results to be retrieved. Leave empty for the initial export request. schema: type: string responses: '200': description: OK content: application/json: schema: type: object additionalProperties: type: object properties: {} '400': description: Bad request content: {} deprecated: false components: securitySchemes: AccessToken: type: apiKey in: header name: Authorization description: > This key is used for all apis with the exception of ingest. You can obtain it following [these instructions](https://docs.mezmo.com/docs/ingestion-key) and placing the key in the header of your call in the format of `Authorization: Token {accesstoken}` For example: ``` curl -H 'Authorization: Token ' ``` servicekeyAuth: type: apiKey in: header name: servicekey description: > (Deprecated) This key is used for v1 and v2 apis with the exception of ingest. Service keys can be used by placing your service key in the `Authorization` header of your api call. *NOTE* Usage of the service key auth mechanism has been deprecated in favor of IAM Access Tokens. Service keys can no longer be created, but can still be used for v1 and v2 apis while the transition takes place ````