- Fleet and Elastic Agent Guide: other versions:
- Fleet and Elastic Agent overview
- Beats and Elastic Agent capabilities
- Quick starts
- Migrate from Beats to Elastic Agent
- Deployment models
- Install Elastic Agents
- Install Fleet-managed Elastic Agents
- Install standalone Elastic Agents
- Install Elastic Agents in a containerized environment
- Run Elastic Agent in a container
- Run Elastic Agent on Kubernetes managed by Fleet
- Install Elastic Agent on Kubernetes using Helm
- Example: Install standalone Elastic Agent on Kubernetes using Helm
- Example: Install Fleet-managed Elastic Agent on Kubernetes using Helm
- Advanced Elastic Agent configuration managed by Fleet
- Configuring Kubernetes metadata enrichment on Elastic Agent
- Run Elastic Agent on GKE managed by Fleet
- Run Elastic Agent on Amazon EKS managed by Fleet
- Run Elastic Agent on Azure AKS managed by Fleet
- Run Elastic Agent Standalone on Kubernetes
- Scaling Elastic Agent on Kubernetes
- Using a custom ingest pipeline with the Kubernetes Integration
- Environment variables
- Run Elastic Agent as an OTel Collector
- Run Elastic Agent without administrative privileges
- Install Elastic Agent from an MSI package
- Installation layout
- Air-gapped environments
- Using a proxy server with Elastic Agent and Fleet
- Uninstall Elastic Agents from edge hosts
- Start and stop Elastic Agents on edge hosts
- Elastic Agent configuration encryption
- Secure connections
- Manage Elastic Agents in Fleet
- Configure standalone Elastic Agents
- Create a standalone Elastic Agent policy
- Structure of a config file
- Inputs
- Providers
- Outputs
- SSL/TLS
- Logging
- Feature flags
- Agent download
- Config file examples
- Grant standalone Elastic Agents access to Elasticsearch
- Example: Use standalone Elastic Agent with Elastic Cloud Serverless to monitor nginx
- Example: Use standalone Elastic Agent with Elasticsearch Service to monitor nginx
- Debug standalone Elastic Agents
- Kubernetes autodiscovery with Elastic Agent
- Monitoring
- Reference YAML
- Manage integrations
- Package signatures
- Add an integration to an Elastic Agent policy
- View integration policies
- Edit or delete an integration policy
- Install and uninstall integration assets
- View integration assets
- Set integration-level outputs
- Upgrade an integration
- Managed integrations content
- Best practices for integrations assets
- Data streams
- Define processors
- Processor syntax
- add_cloud_metadata
- add_cloudfoundry_metadata
- add_docker_metadata
- add_fields
- add_host_metadata
- add_id
- add_kubernetes_metadata
- add_labels
- add_locale
- add_network_direction
- add_nomad_metadata
- add_observer_metadata
- add_process_metadata
- add_tags
- community_id
- convert
- copy_fields
- decode_base64_field
- decode_cef
- decode_csv_fields
- decode_duration
- decode_json_fields
- decode_xml
- decode_xml_wineventlog
- decompress_gzip_field
- detect_mime_type
- dissect
- dns
- drop_event
- drop_fields
- extract_array
- fingerprint
- include_fields
- move_fields
- parse_aws_vpc_flow_log
- rate_limit
- registered_domain
- rename
- replace
- script
- syslog
- timestamp
- translate_sid
- truncate_fields
- urldecode
- Command reference
- Troubleshoot
- Release notes
Timestamp
editTimestamp
editThis functionality is in beta and is subject to change. The design and code is less mature than official GA features and is being provided as-is with no warranties. Beta features are not subject to the support SLA of official GA features.
The timestamp
processor parses a timestamp from a field. By default the
timestamp processor writes the parsed result to the @timestamp
field. You can
specify a different field by setting the target_field
parameter. The timestamp
value is parsed according to the layouts
parameter. Multiple layouts can be
specified and they will be used sequentially to attempt parsing the timestamp
field.
The timestamp layouts used by this processor are different than the formats supported by date processors in Logstash and Elasticsearch Ingest Node.
The layouts
are described using a reference time that is based on this
specific time:
Mon Jan 2 15:04:05 MST 2006
Since MST is GMT-0700, the reference time is:
01/02 03:04:05PM '06 -0700
To define your own layout, rewrite the reference time in a format that matches the timestamps you expect to parse. For more layout examples and details see the Go time package documentation.
If a layout does not contain a year then the current year in the specified
timezone
is added to the time value.
Example
editHere is an example that parses the start_time
field and writes the result
to the @timestamp
field then deletes the start_time
field. When the
processor is loaded, it will immediately validate that the two test
timestamps
parse with this configuration.
- timestamp: field: start_time layouts: - '2006-01-02T15:04:05Z' - '2006-01-02T15:04:05.999Z' - '2006-01-02T15:04:05.999-07:00' test: - '2019-06-22T16:33:51Z' - '2019-11-18T04:59:51.123Z' - '2020-08-03T07:10:20.123456+02:00' - drop_fields: fields: [start_time]
Configuration settings
editElastic Agent processors execute before ingest pipelines, which means that your processor configurations cannot refer to fields that are created by ingest pipelines or Logstash. For more limitations, refer to What are some limitations of using processors?
Name | Required | Default | Description |
---|---|---|---|
|
Yes |
Source field containing the time to be parsed. |
|
|
No |
|
Target field for the parsed time value. The target value is always written as UTC. |
|
Yes |
Timestamp layouts that define the expected time value format. In addition layouts, |
|
|
No |
|
IANA time zone name (for example, |
|
No |
|
Whether to ignore errors when the source field is missing. |
|
No |
|
Whether to gnore all errors produced by the processor. |
|
No |
List of timestamps that must parse successfully when loading the processor. |
|
|
No |
Identifier for this processor instance. Useful for debugging. |
On this page