> ## 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. # Send Log Lines > Use this method to send logs to a logging instance. ### Authentication You can find instructions on authentication [here](/log-analysis-api/ref#authentication). Ingestion is similar to the other APIs, but instead of `servicekey` you will use `apikey` if you are using the header style authentication. ### Metadata Meta is a field reserved for custom information associated with a log line. To add metadata to an API call, specify the `meta` field under the lines object. Metadata can be viewed inside that line's context WARNING: If inconsistent value types are used, that line's metadata, will not be parsed. For example, if a line is passed with a meta object, such as `meta.myfield` of type String, any subsequent lines with `meta.myfield` must have a String as the value type for `meta.myfield`. > Please be aware of [service limits](https://docs.mezmo.com/docs/Mezmo-ingestion-service-limits) > on this endpoint ## OpenAPI ````yaml /log-analysis.json post /logs/ingest 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: /logs/ingest: servers: - url: https://logs.mezmo.com post: tags: - Ingestion summary: Send Log Lines description: > Use this method to send logs to a logging instance. ### Authentication You can find instructions on authentication [here](/log-analysis-api/ref#authentication). Ingestion is similar to the other APIs, but instead of `servicekey` you will use `apikey` if you are using the header style authentication. ### Metadata Meta is a field reserved for custom information associated with a log line. To add metadata to an API call, specify the `meta` field under the lines object. Metadata can be viewed inside that line's context WARNING: If inconsistent value types are used, that line's metadata, will not be parsed. For example, if a line is passed with a meta object, such as `meta.myfield` of type String, any subsequent lines with `meta.myfield` must have a String as the value type for `meta.myfield`. > Please be aware of [service limits](https://docs.mezmo.com/docs/Mezmo-ingestion-service-limits) > on this endpoint operationId: ingest parameters: - name: hostname in: query description: Host name of the source. required: true schema: type: string - name: mac in: query description: The network mac address of the host computer. schema: $ref: '#/components/schemas/mac' - name: ip in: query description: The local IP address of the host computer. schema: $ref: '#/components/schemas/ip' - name: now in: query description: >- The source UNIX timestamp in milliseconds at the time of the request. Used to calculate time drift. schema: type: string - name: tags in: query description: Tags that are used to dynamically group hosts. schema: type: string requestBody: description: You can send multiple log lines in a request. content: application/json: schema: $ref: '#/components/schemas/ingestlines' required: true responses: '200': description: OK content: application/json: schema: type: object additionalProperties: type: object properties: {} '401': description: Unauthorized content: {} '403': description: Forbidden content: {} '404': description: Not Found content: {} deprecated: false security: - apikeyAuth: [] - basicAuth: [] components: schemas: mac: type: string description: The network mac address of the host computer. pattern: ^([0-9A-Fa-f]{2}[:-]){5}([0-9A-Fa-f]{2})$ example: 01:02:03:04:ab:cd ip: type: string description: The local IP address of the host computer (ipv4 or ipv6) example: 10.0.1.111 ingestlines: type: object properties: lines: type: array items: type: object required: - line properties: timestamp: $ref: '#/components/schemas/timestamp' line: $ref: '#/components/schemas/line' app: $ref: '#/components/schemas/app' level: $ref: '#/components/schemas/level' meta: $ref: '#/components/schemas/meta' timestamp: type: string description: UNIX timestamp, including milliseconds, when the log entry was recorded. line: type: string description: Text of the log line. app: type: string description: Name of the application that generates the log line. level: type: string description: >- Set a value for the level. For example, sample values for this parameter are INFO, WARNING, ERROR. meta: type: string description: >- This field is reserved for custom information that is associated with a log line. To add metadata to an API call, specify the meta field under the lines object. Metadata can be viewed inside that line's context. 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 apikeyAuth: type: apiKey in: header name: apikey description: > (Deprecated) This key is used for ingestion. You can obtain it following [these instructions](https://docs.mezmo.com/docs/ingestion-key) and placing the key in the header of your call. *NOTE* Usage of the apikey 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 basicAuth: type: http scheme: basic description: > (Deprecated) As an alternative to authenticating with a header value, you can also use basic authentication. To use either `apiKey` or `servicekey` as basic authentication, simply pass the key as the username with no password. For example: ``` curl https://api.logdna.com/v1/config/view -u INSERT_API_KEY: ``` ````