From 91927d7450f313cf9d3b0297d24ebf02511c70d0 Mon Sep 17 00:00:00 2001 From: Karen Metts <35154725+karenzone@users.noreply.github.com> Date: Mon, 10 Mar 2025 18:02:14 -0400 Subject: [PATCH] Doc: Migrate docs from AsciiDoc to Markdown in 9.0 branch (#17289) * Doc: Delete asciidoc files for 9.0 branch * Add MD files for 9.0 branch --- docs/docset.yml | 493 ++++++ docs/extend/codec-new-plugin.md | 636 ++++++++ docs/extend/community-maintainer.md | 193 +++ docs/extend/contribute-to-core.md | 11 + docs/extend/contributing-patch-plugin.md | 386 +++++ docs/extend/create-logstash-plugins.md | 47 + docs/extend/filter-new-plugin.md | 637 ++++++++ docs/extend/index.md | 58 + docs/extend/input-new-plugin.md | 674 ++++++++ docs/extend/java-codec-plugin.md | 348 +++++ docs/extend/java-filter-plugin.md | 307 ++++ docs/extend/java-input-plugin.md | 341 ++++ docs/extend/java-output-plugin.md | 311 ++++ docs/extend/output-new-plugin.md | 570 +++++++ docs/extend/plugin-doc.md | 172 ++ docs/extend/plugin-listing.md | 23 + docs/extend/publish-plugin.md | 62 + docs/extend/toc.yml | 18 + docs/gs-index.asciidoc | 38 - .../images/basic_logstash_pipeline.png | Bin .../images/centralized_config.png | Bin .../{static => }/images/dead_letter_queue.png | Bin docs/{static => }/images/deploy1.png | Bin docs/{static => }/images/deploy2.png | Bin docs/{static => }/images/deploy3.png | Bin docs/{static => }/images/deploy4.png | Bin .../images/integration-assets-dashboards.png | Bin .../images/integration-dashboard-overview.png | Bin .../images/kibana-filebeat-data.png | Bin .../monitoring => }/images/kibana-home.png | Bin .../monitoring => }/images/monitoring-ui.png | Bin .../monitoring => }/images/nodestats.png | Bin .../monitoring => }/images/overviewstats.png | Bin .../images/pipeline-input-detail.png | Bin .../monitoring => }/images/pipeline-tree.png | Bin .../images/pipeline_correct_load.png | Bin .../{static => }/images/pipeline_overload.png | Bin docs/include/attributes-ls.asciidoc | 10 - docs/include/attributes-lsplugins.asciidoc | 13 - docs/include/filter.asciidoc | 234 --- docs/include/input.asciidoc | 172 -- docs/include/output.asciidoc | 94 -- docs/include/plugin_header-core.asciidoc | 14 - .../plugin_header-integration.asciidoc | 19 - docs/include/plugin_header.asciidoc | 25 - docs/include/version-list-intro.asciidoc | 14 - docs/index.asciidoc | 238 --- docs/index.x.asciidoc | 1 - .../advanced-logstash-configurations.md | 14 + docs/reference/advanced-pipeline.md | 612 ++++++++ docs/reference/codec-plugins.md | 67 + .../config-examples.md} | 145 +- docs/reference/config-setting-files.md | 33 + .../reference/configuration-file-structure.md | 235 +++ .../configuring-centralized-pipelines.md | 157 ++ .../configuring-geoip-database-management.md | 68 + docs/reference/connecting-to-cloud.md | 47 + docs/reference/core-operations.md | 92 ++ docs/reference/creating-logstash-pipeline.md | 34 + ...dashboard-monitoring-with-elastic-agent.md | 145 ++ docs/reference/data-deserialization.md | 105 ++ docs/reference/dead-letter-queues.md | 257 +++ docs/reference/deploying-scaling-logstash.md | 165 ++ docs/reference/dir-layout.md | 59 + docs/reference/docker-config.md | 130 ++ docs/reference/docker.md | 31 + docs/reference/ecs-ls.md | 78 + .../environment-variables.md} | 103 +- docs/reference/event-api.md | 105 ++ .../event-dependent-configuration.md | 371 +++++ docs/reference/execution-model.md | 13 + docs/reference/field-extraction.md | 102 ++ docs/reference/filter-plugins.md | 113 ++ docs/reference/first-event.md | 70 + .../getting-started-with-logstash.md | 121 ++ docs/reference/glob-support.md | 44 + docs/reference/how-logstash-works.md | 59 + docs/reference/index.md | 8 + docs/reference/input-plugins.md | 129 ++ docs/reference/installing-logstash.md | 63 + docs/reference/integration-plugins.md | 27 + docs/reference/jvm-settings.md | 152 ++ docs/reference/keystore.md | 159 ++ docs/reference/logging.md | 227 +++ ...ogstash-centralized-pipeline-management.md | 78 + .../logstash-geoip-database-management.md | 78 + docs/reference/logstash-monitoring-ui.md | 28 + docs/reference/logstash-pipeline-viewer.md | 55 + docs/reference/logstash-settings-file.md | 96 ++ .../logstash-to-logstash-communications.md | 42 + docs/reference/lookup-enrichment.md | 236 +++ docs/reference/ls-to-ls-http.md | 137 ++ .../ls-to-ls-lumberjack.md} | 80 +- docs/reference/ls-to-ls-native.md | 133 ++ docs/reference/managing-geoip-databases.md | 14 + docs/reference/managing-logstash.md | 13 + docs/reference/memory-queue.md | 65 + .../monitoring-internal-collection-legacy.md | 276 ++++ docs/reference/monitoring-logstash-legacy.md | 23 + .../monitoring-logstash-with-elastic-agent.md | 20 + docs/reference/monitoring-logstash.md | 97 ++ docs/reference/monitoring-troubleshooting.md | 30 + .../monitoring-with-elastic-agent.md | 146 ++ docs/reference/monitoring-with-metricbeat.md | 156 ++ docs/reference/multiline.md | 113 ++ .../multiple-input-output-plugins.md | 174 +++ .../multiple-pipelines.md} | 32 +- docs/reference/offline-plugins.md | 78 + docs/reference/output-plugins.md | 133 ++ docs/reference/performance-troubleshooting.md | 56 + docs/reference/performance-tuning.md | 14 + docs/reference/persistent-queues.md | 368 +++++ .../pipeline-to-pipeline.md} | 125 +- docs/reference/plugin-concepts.md | 26 + docs/reference/plugin-generator.md | 18 + docs/reference/plugins-codecs-avro.md | 148 ++ docs/reference/plugins-codecs-cef.md | 524 +++++++ docs/reference/plugins-codecs-cloudfront.md | 47 + docs/reference/plugins-codecs-cloudtrail.md | 41 + docs/reference/plugins-codecs-collectd.md | 153 ++ docs/reference/plugins-codecs-csv.md | 178 +++ docs/reference/plugins-codecs-dots.md | 25 + docs/reference/plugins-codecs-edn.md | 56 + docs/reference/plugins-codecs-edn_lines.md | 56 + docs/reference/plugins-codecs-es_bulk.md | 79 + docs/reference/plugins-codecs-fluent.md | 87 ++ docs/reference/plugins-codecs-graphite.md | 93 ++ docs/reference/plugins-codecs-gzip_lines.md | 51 + docs/reference/plugins-codecs-java_line.md | 60 + docs/reference/plugins-codecs-java_plain.md | 47 + docs/reference/plugins-codecs-jdots.md | 25 + docs/reference/plugins-codecs-json.md | 91 ++ docs/reference/plugins-codecs-json_lines.md | 103 ++ docs/reference/plugins-codecs-line.md | 75 + docs/reference/plugins-codecs-msgpack.md | 62 + docs/reference/plugins-codecs-multiline.md | 225 +++ docs/reference/plugins-codecs-netflow.md | 207 +++ docs/reference/plugins-codecs-nmap.md | 80 + docs/reference/plugins-codecs-plain.md | 77 + docs/reference/plugins-codecs-protobuf.md | 247 +++ docs/reference/plugins-codecs-rubydebug.md | 42 + docs/reference/plugins-filters-age.md | 231 +++ docs/reference/plugins-filters-aggregate.md | 757 +++++++++ docs/reference/plugins-filters-alter.md | 283 ++++ docs/reference/plugins-filters-bytes.md | 284 ++++ docs/reference/plugins-filters-cidr.md | 277 ++++ docs/reference/plugins-filters-cipher.md | 387 +++++ docs/reference/plugins-filters-clone.md | 317 ++++ docs/reference/plugins-filters-csv.md | 345 ++++ docs/reference/plugins-filters-date.md | 423 +++++ docs/reference/plugins-filters-de_dot.md | 249 +++ docs/reference/plugins-filters-dissect.md | 531 +++++++ docs/reference/plugins-filters-dns.md | 347 +++++ docs/reference/plugins-filters-drop.md | 242 +++ docs/reference/plugins-filters-elapsed.md | 326 ++++ .../plugins-filters-elastic_integration.md | 674 ++++++++ .../plugins-filters-elasticsearch.md | 679 ++++++++ docs/reference/plugins-filters-environment.md | 246 +++ .../plugins-filters-extractnumbers.md | 226 +++ docs/reference/plugins-filters-fingerprint.md | 351 +++++ docs/reference/plugins-filters-geoip.md | 508 ++++++ docs/reference/plugins-filters-grok.md | 586 +++++++ docs/reference/plugins-filters-http.md | 620 ++++++++ docs/reference/plugins-filters-i18n.md | 230 +++ docs/reference/plugins-filters-java_uuid.md | 246 +++ docs/reference/plugins-filters-jdbc_static.md | 672 ++++++++ .../plugins-filters-jdbc_streaming.md | 466 ++++++ docs/reference/plugins-filters-json.md | 305 ++++ docs/reference/plugins-filters-json_encode.md | 243 +++ docs/reference/plugins-filters-kv.md | 687 ++++++++ docs/reference/plugins-filters-memcached.md | 347 +++++ docs/reference/plugins-filters-metricize.md | 280 ++++ docs/reference/plugins-filters-metrics.md | 387 +++++ docs/reference/plugins-filters-mutate.md | 600 +++++++ docs/reference/plugins-filters-prune.md | 318 ++++ docs/reference/plugins-filters-range.md | 249 +++ docs/reference/plugins-filters-ruby.md | 404 +++++ docs/reference/plugins-filters-sleep.md | 276 ++++ docs/reference/plugins-filters-split.md | 261 ++++ docs/reference/plugins-filters-syslog_pri.md | 266 ++++ .../plugins-filters-threats_classifier.md | 32 + docs/reference/plugins-filters-throttle.md | 396 +++++ docs/reference/plugins-filters-tld.md | 235 +++ docs/reference/plugins-filters-translate.md | 563 +++++++ docs/reference/plugins-filters-truncate.md | 239 +++ docs/reference/plugins-filters-urldecode.md | 244 +++ docs/reference/plugins-filters-useragent.md | 354 +++++ docs/reference/plugins-filters-uuid.md | 250 +++ .../plugins-filters-wurfl_device_detection.md | 35 + docs/reference/plugins-filters-xml.md | 362 +++++ .../plugins-inputs-azure_event_hubs.md | 538 +++++++ docs/reference/plugins-inputs-beats.md | 480 ++++++ docs/reference/plugins-inputs-cloudwatch.md | 395 +++++ .../plugins-inputs-couchdb_changes.md | 279 ++++ .../plugins-inputs-dead_letter_queue.md | 191 +++ .../reference/plugins-inputs-elastic_agent.md | 443 ++++++ ...ins-inputs-elastic_serverless_forwarder.md | 383 +++++ .../reference/plugins-inputs-elasticsearch.md | 683 ++++++++ docs/reference/plugins-inputs-exec.md | 252 +++ docs/reference/plugins-inputs-file.md | 489 ++++++ docs/reference/plugins-inputs-ganglia.md | 138 ++ docs/reference/plugins-inputs-gelf.md | 201 +++ docs/reference/plugins-inputs-generator.md | 226 +++ docs/reference/plugins-inputs-github.md | 162 ++ .../plugins-inputs-google_cloud_storage.md | 359 +++++ .../reference/plugins-inputs-google_pubsub.md | 308 ++++ docs/reference/plugins-inputs-graphite.md | 240 +++ docs/reference/plugins-inputs-heartbeat.md | 221 +++ docs/reference/plugins-inputs-http.md | 519 ++++++ docs/reference/plugins-inputs-http_poller.md | 634 ++++++++ docs/reference/plugins-inputs-imap.md | 303 ++++ docs/reference/plugins-inputs-irc.md | 230 +++ .../plugins-inputs-java_generator.md | 185 +++ docs/reference/plugins-inputs-java_stdin.md | 111 ++ docs/reference/plugins-inputs-jdbc.md | 696 +++++++++ docs/reference/plugins-inputs-jms.md | 821 ++++++++++ docs/reference/plugins-inputs-jmx.md | 237 +++ docs/reference/plugins-inputs-kafka.md | 883 +++++++++++ docs/reference/plugins-inputs-kinesis.md | 282 ++++ docs/reference/plugins-inputs-log4j.md | 248 +++ docs/reference/plugins-inputs-logstash.md | 293 ++++ docs/reference/plugins-inputs-lumberjack.md | 191 +++ docs/reference/plugins-inputs-meetup.md | 190 +++ docs/reference/plugins-inputs-pipe.md | 190 +++ .../reference/plugins-inputs-puppet_facter.md | 174 +++ docs/reference/plugins-inputs-rabbitmq.md | 438 ++++++ docs/reference/plugins-inputs-redis.md | 241 +++ docs/reference/plugins-inputs-relp.md | 204 +++ docs/reference/plugins-inputs-rss.md | 150 ++ docs/reference/plugins-inputs-s3-sns-sqs.md | 32 + docs/reference/plugins-inputs-s3.md | 409 +++++ docs/reference/plugins-inputs-salesforce.md | 292 ++++ docs/reference/plugins-inputs-snmp.md | 543 +++++++ docs/reference/plugins-inputs-snmptrap.md | 440 ++++++ docs/reference/plugins-inputs-sqlite.md | 208 +++ docs/reference/plugins-inputs-sqs.md | 355 +++++ docs/reference/plugins-inputs-stdin.md | 140 ++ docs/reference/plugins-inputs-stomp.md | 199 +++ docs/reference/plugins-inputs-syslog.md | 264 ++++ docs/reference/plugins-inputs-tcp.md | 408 +++++ docs/reference/plugins-inputs-twitter.md | 341 ++++ docs/reference/plugins-inputs-udp.md | 225 +++ docs/reference/plugins-inputs-unix.md | 223 +++ docs/reference/plugins-inputs-varnishlog.md | 132 ++ docs/reference/plugins-inputs-websocket.md | 144 ++ docs/reference/plugins-inputs-wmi.md | 202 +++ docs/reference/plugins-inputs-xmpp.md | 165 ++ docs/reference/plugins-integrations-aws.md | 35 + ...-integrations-elastic_enterprise_search.md | 27 + docs/reference/plugins-integrations-jdbc.md | 29 + docs/reference/plugins-integrations-kafka.md | 30 + .../plugins-integrations-logstash.md | 77 + .../plugins-integrations-rabbitmq.md | 28 + docs/reference/plugins-integrations-snmp.md | 168 ++ docs/reference/plugins-outputs-boundary.md | 168 ++ docs/reference/plugins-outputs-circonus.md | 134 ++ docs/reference/plugins-outputs-cloudwatch.md | 307 ++++ docs/reference/plugins-outputs-csv.md | 190 +++ docs/reference/plugins-outputs-datadog.md | 165 ++ .../plugins-outputs-datadog_metrics.md | 181 +++ docs/reference/plugins-outputs-dynatrace.md | 32 + .../plugins-outputs-elastic_app_search.md | 250 +++ ...lugins-outputs-elastic_workplace_search.md | 262 ++++ .../plugins-outputs-elasticsearch.md | 1242 +++++++++++++++ docs/reference/plugins-outputs-email.md | 293 ++++ docs/reference/plugins-outputs-exec.md | 129 ++ docs/reference/plugins-outputs-file.md | 176 +++ docs/reference/plugins-outputs-ganglia.md | 182 +++ docs/reference/plugins-outputs-gelf.md | 205 +++ .../plugins-outputs-google_bigquery.md | 423 +++++ .../plugins-outputs-google_cloud_storage.md | 307 ++++ .../plugins-outputs-google_pubsub.md | 253 +++ docs/reference/plugins-outputs-graphite.md | 203 +++ docs/reference/plugins-outputs-graphtastic.md | 179 +++ docs/reference/plugins-outputs-http.md | 513 ++++++ docs/reference/plugins-outputs-influxdb.md | 291 ++++ docs/reference/plugins-outputs-irc.md | 202 +++ docs/reference/plugins-outputs-java_stdout.md | 92 ++ docs/reference/plugins-outputs-juggernaut.md | 158 ++ docs/reference/plugins-outputs-kafka.md | 600 +++++++ docs/reference/plugins-outputs-librato.md | 213 +++ docs/reference/plugins-outputs-loggly.md | 231 +++ docs/reference/plugins-outputs-logstash.md | 299 ++++ docs/reference/plugins-outputs-lumberjack.md | 139 ++ .../plugins-outputs-metriccatcher.md | 198 +++ docs/reference/plugins-outputs-mongodb.md | 174 +++ docs/reference/plugins-outputs-nagios.md | 129 ++ docs/reference/plugins-outputs-nagios_nsca.md | 180 +++ docs/reference/plugins-outputs-opentsdb.md | 131 ++ docs/reference/plugins-outputs-pagerduty.md | 145 ++ docs/reference/plugins-outputs-pipe.md | 117 ++ docs/reference/plugins-outputs-rabbitmq.md | 296 ++++ docs/reference/plugins-outputs-redis.md | 312 ++++ docs/reference/plugins-outputs-redmine.md | 229 +++ docs/reference/plugins-outputs-riak.md | 213 +++ docs/reference/plugins-outputs-riemann.md | 215 +++ docs/reference/plugins-outputs-s3.md | 458 ++++++ docs/reference/plugins-outputs-sink.md | 74 + docs/reference/plugins-outputs-sns.md | 198 +++ docs/reference/plugins-outputs-solr_http.md | 136 ++ docs/reference/plugins-outputs-sqs.md | 266 ++++ docs/reference/plugins-outputs-statsd.md | 229 +++ docs/reference/plugins-outputs-stdout.md | 104 ++ docs/reference/plugins-outputs-stomp.md | 168 ++ docs/reference/plugins-outputs-syslog.md | 267 ++++ docs/reference/plugins-outputs-tcp.md | 250 +++ docs/reference/plugins-outputs-timber.md | 243 +++ docs/reference/plugins-outputs-udp.md | 127 ++ docs/reference/plugins-outputs-webhdfs.md | 332 ++++ docs/reference/plugins-outputs-websocket.md | 112 ++ docs/reference/plugins-outputs-xmpp.md | 149 ++ docs/reference/plugins-outputs-zabbix.md | 190 +++ docs/reference/private-rubygem.md | 55 + docs/reference/processing.md | 48 + docs/reference/queues-data-resiliency.md | 21 + docs/reference/reloading-config.md | 58 + .../running-logstash-command-line.md | 165 ++ docs/reference/running-logstash-kubernetes.md | 9 + docs/reference/running-logstash-windows.md | 198 +++ docs/reference/running-logstash.md | 27 + docs/reference/secure-connection.md | 498 ++++++ ...erverless-monitoring-with-elastic-agent.md | 68 + docs/reference/setting-up-running-logstash.md | 36 + .../shutdown.md} | 87 +- docs/reference/tips-best-practices.md | 118 ++ docs/reference/toc.yml | 330 ++++ docs/reference/transforming-data.md | 20 + docs/reference/tuning-logstash.md | 80 + docs/reference/upgrading-logstash-9-0.md | 34 + docs/reference/upgrading-logstash.md | 73 + docs/reference/upgrading-minor-versions.md | 11 + .../upgrading-using-direct-download.md | 18 + .../upgrading-using-package-managers.md | 15 + docs/reference/use-filebeat-modules-kafka.md | 119 ++ docs/reference/use-ingest-pipelines.md | 65 + ...sing-logstash-with-elastic-integrations.md | 87 ++ .../working-with-filebeat-modules.md | 13 + docs/reference/working-with-plugins.md | 145 ++ .../working-with-winlogbeat-modules.md | 70 + docs/release-notes/breaking-changes.md | 206 +++ docs/release-notes/deprecations.md | 28 + docs/release-notes/index.md | 32 + docs/release-notes/known-issues.md | 7 + docs/release-notes/toc.yml | 5 + docs/static/advanced-pipeline.asciidoc | 868 ----------- docs/static/best-practice.asciidoc | 149 -- docs/static/breaking-changes-60.asciidoc | 58 - docs/static/breaking-changes-70.asciidoc | 195 --- docs/static/breaking-changes-80.asciidoc | 73 - docs/static/breaking-changes-90.asciidoc | 265 ---- docs/static/breaking-changes.asciidoc | 39 - docs/static/codec.asciidoc | 15 - docs/static/config-details.asciidoc | 210 --- docs/static/config-management.asciidoc | 12 - docs/static/configuration-advanced.asciidoc | 6 - docs/static/contrib-acceptance.asciidoc | 19 - docs/static/contribute-core.asciidoc | 10 - docs/static/contributing-java-plugin.asciidoc | 50 - docs/static/contributing-patch.asciidoc | 407 ----- docs/static/contributing-to-logstash.asciidoc | 44 - .../core-plugins/codecs/java_dots.asciidoc | 24 - .../core-plugins/codecs/java_line.asciidoc | 63 - .../core-plugins/codecs/java_plain.asciidoc | 51 - .../core-plugins/filters/java_uuid.asciidoc | 91 -- .../inputs/java_generator.asciidoc | 117 -- .../core-plugins/inputs/java_stdin.asciidoc | 35 - .../core-plugins/outputs/java_sink.asciidoc | 33 - .../core-plugins/outputs/java_stdout.asciidoc | 50 - docs/static/cross-plugin-concepts.asciidoc | 26 - docs/static/dead-letter-queues.asciidoc | 348 ----- docs/static/deploying.asciidoc | 251 --- docs/static/doc-for-plugin.asciidoc | 191 --- docs/static/docker.asciidoc | 229 --- docs/static/ea-integrations.asciidoc | 95 -- docs/static/ecs-compatibility.asciidoc | 87 -- docs/static/event-api.asciidoc | 120 -- docs/static/event-data.asciidoc | 439 ------ docs/static/fb-ls-kafka-example.asciidoc | 159 -- docs/static/field-reference.asciidoc | 147 -- docs/static/filebeat-modules.asciidoc | 191 --- docs/static/filter.asciidoc | 14 - .../static/geoip-database-management.asciidoc | 10 - .../configuring.asciidoc | 68 - .../geoip-database-management/index.asciidoc | 19 - .../metrics.asciidoc | 56 - .../getting-started-with-logstash.asciidoc | 317 ---- docs/static/glob-support.asciidoc | 50 - docs/static/images/arcsight-diagram-adp.svg | 414 ----- .../arcsight-diagram-smart-connectors.svg | 308 ---- .../images/arcsight-network-overview.png | Bin 1221194 -> 0 bytes .../images/arcsight-network-suspicious.png | Bin 947614 -> 0 bytes docs/static/images/azure-flow.png | Bin 230253 -> 0 bytes docs/static/images/deploy_1.png | Bin 33995 -> 0 bytes docs/static/images/deploy_2.png | Bin 46477 -> 0 bytes docs/static/images/deploy_3.png | Bin 41921 -> 0 bytes docs/static/images/deploy_4.png | Bin 57848 -> 0 bytes docs/static/images/deploy_5.png | Bin 107951 -> 0 bytes docs/static/images/deploy_6.png | Bin 167866 -> 0 bytes docs/static/images/deploy_7.png | Bin 175897 -> 0 bytes .../images/logstash-module-overview.png | Bin 31634 -> 0 bytes docs/static/images/logstash.png | Bin 52106 -> 0 bytes .../images/netflow-conversation-partners.png | Bin 263522 -> 0 bytes docs/static/images/netflow-geo-location.png | Bin 685997 -> 0 bytes docs/static/images/netflow-overview.png | Bin 339232 -> 0 bytes .../images/netflow-traffic-analysis.png | Bin 411714 -> 0 bytes docs/static/include/javapluginpkg.asciidoc | 83 - docs/static/include/javapluginsetup.asciidoc | 52 - docs/static/include/pluginbody.asciidoc | 1268 --------------- docs/static/input.asciidoc | 12 - docs/static/introduction.asciidoc | 122 -- docs/static/java-codec.asciidoc | 357 ----- docs/static/java-filter.asciidoc | 304 ---- docs/static/java-input.asciidoc | 317 ---- docs/static/java-output.asciidoc | 286 ---- docs/static/jvm.asciidoc | 122 -- docs/static/keystore.asciidoc | 184 --- docs/static/life-of-an-event.asciidoc | 99 -- docs/static/listing-a-plugin.asciidoc | 17 - docs/static/logging.asciidoc | 251 --- docs/static/logstash-glossary.asciidoc | 132 -- docs/static/ls-ls-config.asciidoc | 40 - docs/static/ls-ls-http.asciidoc | 136 -- docs/static/ls-ls-native.asciidoc | 128 -- docs/static/ls-to-cloud.asciidoc | 58 - docs/static/maintainer-guide.asciidoc | 222 --- .../management/centralized-pipelines.asciidoc | 112 -- ...configuring-centralized-pipelines.asciidoc | 42 - .../static/management/images/new_pipeline.png | Bin 158231 -> 0 bytes .../static/managing-multiline-events.asciidoc | 113 -- docs/static/mem-queue.asciidoc | 65 - .../monitoring/collectors-legacy.asciidoc | 49 - .../integration-agent-add-standalone.png | Bin 314099 -> 0 bytes .../images/integration-agent-add.png | Bin 222831 -> 0 bytes .../images/integration-agent-confirm.png | Bin 97202 -> 0 bytes .../monitoring/images/pipeline-diagram.png | Bin 285242 -> 0 bytes .../images/pipeline-filter-detail.png | Bin 9547 -> 0 bytes .../images/pipeline-output-detail.png | Bin 8034 -> 0 bytes .../images/pipeline-viewer-detail-drawer.png | Bin 373722 -> 0 bytes .../images/pipeline-viewer-overview.png | Bin 158608 -> 0 bytes .../monitoring/monitoring-apis.asciidoc | 1386 ----------------- .../monitoring-ea-dashboards.asciidoc | 117 -- .../monitoring/monitoring-ea-intro.asciidoc | 34 - .../monitoring-ea-serverless.asciidoc | 73 - docs/static/monitoring/monitoring-ea.asciidoc | 118 -- .../monitoring/monitoring-install.asciidoc | 11 - .../monitoring-internal-legacy.asciidoc | 173 -- docs/static/monitoring/monitoring-mb.asciidoc | 205 --- .../monitoring-output-legacy.asciidoc | 47 - .../monitoring/monitoring-overview.asciidoc | 36 - .../monitoring-prereq-create-user.asciidoc | 5 - .../monitoring-prereq-define-cluster.asciidoc | 10 - ...monitoring-prereq-disable-default.asciidoc | 9 - .../monitoring-prereq-setup-es.asciidoc | 5 - docs/static/monitoring/monitoring-ui.asciidoc | 23 - .../monitoring/monitoring-view.asciidoc | 14 - docs/static/monitoring/monitoring.asciidoc | 26 - .../monitoring/pipeline-viewer.asciidoc | 76 - .../monitoring/troubleshooting.asciidoc | 36 - docs/static/offline-plugins.asciidoc | 89 -- docs/static/output.asciidoc | 14 - docs/static/performance-checklist.asciidoc | 179 --- docs/static/persistent-queues.asciidoc | 425 ----- docs/static/pipeline-configuration.asciidoc | 319 ---- docs/static/pipeline-structure.asciidoc | 0 docs/static/plugin-generator.asciidoc | 19 - docs/static/plugin-manager.asciidoc | 179 --- docs/static/private-gem-repo.asciidoc | 53 - docs/static/processing-info.asciidoc | 48 - docs/static/redirects.asciidoc | 156 -- docs/static/releasenotes.asciidoc | 117 -- docs/static/reloading-config.asciidoc | 66 - docs/static/reserved-fields.asciidoc | 39 - docs/static/resiliency.asciidoc | 22 - .../running-logstash-command-line.asciidoc | 235 --- .../running-logstash-kubernetes.asciidoc | 6 - docs/static/running-logstash-windows.asciidoc | 159 -- docs/static/running-logstash.asciidoc | 27 - docs/static/security/api-keys.asciidoc | 293 ---- docs/static/security/basic-auth.asciidoc | 82 - docs/static/security/es-security.asciidoc | 97 -- docs/static/security/grant-access.asciidoc | 42 - docs/static/security/logstash.asciidoc | 32 - docs/static/security/ls-monitoring.asciidoc | 35 - docs/static/security/pipeline-mgmt.asciidoc | 18 - docs/static/security/pki-auth.asciidoc | 22 - docs/static/security/tls-encryption.asciidoc | 23 - docs/static/setting-up-logstash.asciidoc | 196 --- docs/static/settings-file.asciidoc | 346 ---- ...configuration-management-settings.asciidoc | 154 -- ...onfiguration-wildcard-pipeline-id.asciidoc | 19 - ...eoip-database-management-settings.asciidoc | 26 - .../monitoring-settings-legacy.asciidoc | 154 -- docs/static/submitting-a-plugin.asciidoc | 73 - .../tab-widgets/install-agent-widget.asciidoc | 40 - .../static/tab-widgets/install-agent.asciidoc | 25 - docs/static/transforming-data.asciidoc | 648 -------- ...-pipeline-flow-worker-utilization.asciidoc | 44 - .../health-pipeline-status.asciidoc | 37 - .../troubleshoot/plugin-tracing.asciidoc | 96 -- .../troubleshoot/troubleshooting.asciidoc | 32 - docs/static/troubleshoot/ts-azure.asciidoc | 82 - docs/static/troubleshoot/ts-kafka.asciidoc | 191 --- docs/static/troubleshoot/ts-logstash.asciidoc | 338 ---- .../troubleshoot/ts-other-issues.asciidoc | 14 - .../troubleshoot/ts-plugins-general.asciidoc | 5 - docs/static/troubleshoot/ts-plugins.asciidoc | 5 - docs/static/upgrading.asciidoc | 167 -- docs/static/winlogbeat-modules.asciidoc | 90 -- 508 files changed, 67717 insertions(+), 20144 deletions(-) create mode 100644 docs/docset.yml create mode 100644 docs/extend/codec-new-plugin.md create mode 100644 docs/extend/community-maintainer.md create mode 100644 docs/extend/contribute-to-core.md create mode 100644 docs/extend/contributing-patch-plugin.md create mode 100644 docs/extend/create-logstash-plugins.md create mode 100644 docs/extend/filter-new-plugin.md create mode 100644 docs/extend/index.md create mode 100644 docs/extend/input-new-plugin.md create mode 100644 docs/extend/java-codec-plugin.md create mode 100644 docs/extend/java-filter-plugin.md create mode 100644 docs/extend/java-input-plugin.md create mode 100644 docs/extend/java-output-plugin.md create mode 100644 docs/extend/output-new-plugin.md create mode 100644 docs/extend/plugin-doc.md create mode 100644 docs/extend/plugin-listing.md create mode 100644 docs/extend/publish-plugin.md create mode 100644 docs/extend/toc.yml delete mode 100644 docs/gs-index.asciidoc rename docs/{static => }/images/basic_logstash_pipeline.png (100%) rename docs/{static/management => }/images/centralized_config.png (100%) rename docs/{static => }/images/dead_letter_queue.png (100%) rename docs/{static => }/images/deploy1.png (100%) rename docs/{static => }/images/deploy2.png (100%) rename docs/{static => }/images/deploy3.png (100%) rename docs/{static => }/images/deploy4.png (100%) rename docs/{static/monitoring => }/images/integration-assets-dashboards.png (100%) rename docs/{static/monitoring => }/images/integration-dashboard-overview.png (100%) rename docs/{static => }/images/kibana-filebeat-data.png (100%) rename docs/{static/monitoring => }/images/kibana-home.png (100%) rename docs/{static/monitoring => }/images/monitoring-ui.png (100%) rename docs/{static/monitoring => }/images/nodestats.png (100%) rename docs/{static/monitoring => }/images/overviewstats.png (100%) rename docs/{static/monitoring => }/images/pipeline-input-detail.png (100%) rename docs/{static/monitoring => }/images/pipeline-tree.png (100%) rename docs/{static => }/images/pipeline_correct_load.png (100%) rename docs/{static => }/images/pipeline_overload.png (100%) delete mode 100644 docs/include/attributes-ls.asciidoc delete mode 100644 docs/include/attributes-lsplugins.asciidoc delete mode 100644 docs/include/filter.asciidoc delete mode 100644 docs/include/input.asciidoc delete mode 100644 docs/include/output.asciidoc delete mode 100644 docs/include/plugin_header-core.asciidoc delete mode 100644 docs/include/plugin_header-integration.asciidoc delete mode 100644 docs/include/plugin_header.asciidoc delete mode 100644 docs/include/version-list-intro.asciidoc delete mode 100644 docs/index.asciidoc delete mode 100644 docs/index.x.asciidoc create mode 100644 docs/reference/advanced-logstash-configurations.md create mode 100644 docs/reference/advanced-pipeline.md create mode 100644 docs/reference/codec-plugins.md rename docs/{static/pipeline-config-exps.asciidoc => reference/config-examples.md} (64%) create mode 100644 docs/reference/config-setting-files.md create mode 100644 docs/reference/configuration-file-structure.md create mode 100644 docs/reference/configuring-centralized-pipelines.md create mode 100644 docs/reference/configuring-geoip-database-management.md create mode 100644 docs/reference/connecting-to-cloud.md create mode 100644 docs/reference/core-operations.md create mode 100644 docs/reference/creating-logstash-pipeline.md create mode 100644 docs/reference/dashboard-monitoring-with-elastic-agent.md create mode 100644 docs/reference/data-deserialization.md create mode 100644 docs/reference/dead-letter-queues.md create mode 100644 docs/reference/deploying-scaling-logstash.md create mode 100644 docs/reference/dir-layout.md create mode 100644 docs/reference/docker-config.md create mode 100644 docs/reference/docker.md create mode 100644 docs/reference/ecs-ls.md rename docs/{static/env-vars.asciidoc => reference/environment-variables.md} (61%) create mode 100644 docs/reference/event-api.md create mode 100644 docs/reference/event-dependent-configuration.md create mode 100644 docs/reference/execution-model.md create mode 100644 docs/reference/field-extraction.md create mode 100644 docs/reference/filter-plugins.md create mode 100644 docs/reference/first-event.md create mode 100644 docs/reference/getting-started-with-logstash.md create mode 100644 docs/reference/glob-support.md create mode 100644 docs/reference/how-logstash-works.md create mode 100644 docs/reference/index.md create mode 100644 docs/reference/input-plugins.md create mode 100644 docs/reference/installing-logstash.md create mode 100644 docs/reference/integration-plugins.md create mode 100644 docs/reference/jvm-settings.md create mode 100644 docs/reference/keystore.md create mode 100644 docs/reference/logging.md create mode 100644 docs/reference/logstash-centralized-pipeline-management.md create mode 100644 docs/reference/logstash-geoip-database-management.md create mode 100644 docs/reference/logstash-monitoring-ui.md create mode 100644 docs/reference/logstash-pipeline-viewer.md create mode 100644 docs/reference/logstash-settings-file.md create mode 100644 docs/reference/logstash-to-logstash-communications.md create mode 100644 docs/reference/lookup-enrichment.md create mode 100644 docs/reference/ls-to-ls-http.md rename docs/{static/ls-ls-lumberjack.asciidoc => reference/ls-to-ls-lumberjack.md} (61%) create mode 100644 docs/reference/ls-to-ls-native.md create mode 100644 docs/reference/managing-geoip-databases.md create mode 100644 docs/reference/managing-logstash.md create mode 100644 docs/reference/memory-queue.md create mode 100644 docs/reference/monitoring-internal-collection-legacy.md create mode 100644 docs/reference/monitoring-logstash-legacy.md create mode 100644 docs/reference/monitoring-logstash-with-elastic-agent.md create mode 100644 docs/reference/monitoring-logstash.md create mode 100644 docs/reference/monitoring-troubleshooting.md create mode 100644 docs/reference/monitoring-with-elastic-agent.md create mode 100644 docs/reference/monitoring-with-metricbeat.md create mode 100644 docs/reference/multiline.md create mode 100644 docs/reference/multiple-input-output-plugins.md rename docs/{static/multiple-pipelines.asciidoc => reference/multiple-pipelines.md} (53%) create mode 100644 docs/reference/offline-plugins.md create mode 100644 docs/reference/output-plugins.md create mode 100644 docs/reference/performance-troubleshooting.md create mode 100644 docs/reference/performance-tuning.md create mode 100644 docs/reference/persistent-queues.md rename docs/{static/pipeline-pipeline-config.asciidoc => reference/pipeline-to-pipeline.md} (68%) create mode 100644 docs/reference/plugin-concepts.md create mode 100644 docs/reference/plugin-generator.md create mode 100644 docs/reference/plugins-codecs-avro.md create mode 100644 docs/reference/plugins-codecs-cef.md create mode 100644 docs/reference/plugins-codecs-cloudfront.md create mode 100644 docs/reference/plugins-codecs-cloudtrail.md create mode 100644 docs/reference/plugins-codecs-collectd.md create mode 100644 docs/reference/plugins-codecs-csv.md create mode 100644 docs/reference/plugins-codecs-dots.md create mode 100644 docs/reference/plugins-codecs-edn.md create mode 100644 docs/reference/plugins-codecs-edn_lines.md create mode 100644 docs/reference/plugins-codecs-es_bulk.md create mode 100644 docs/reference/plugins-codecs-fluent.md create mode 100644 docs/reference/plugins-codecs-graphite.md create mode 100644 docs/reference/plugins-codecs-gzip_lines.md create mode 100644 docs/reference/plugins-codecs-java_line.md create mode 100644 docs/reference/plugins-codecs-java_plain.md create mode 100644 docs/reference/plugins-codecs-jdots.md create mode 100644 docs/reference/plugins-codecs-json.md create mode 100644 docs/reference/plugins-codecs-json_lines.md create mode 100644 docs/reference/plugins-codecs-line.md create mode 100644 docs/reference/plugins-codecs-msgpack.md create mode 100644 docs/reference/plugins-codecs-multiline.md create mode 100644 docs/reference/plugins-codecs-netflow.md create mode 100644 docs/reference/plugins-codecs-nmap.md create mode 100644 docs/reference/plugins-codecs-plain.md create mode 100644 docs/reference/plugins-codecs-protobuf.md create mode 100644 docs/reference/plugins-codecs-rubydebug.md create mode 100644 docs/reference/plugins-filters-age.md create mode 100644 docs/reference/plugins-filters-aggregate.md create mode 100644 docs/reference/plugins-filters-alter.md create mode 100644 docs/reference/plugins-filters-bytes.md create mode 100644 docs/reference/plugins-filters-cidr.md create mode 100644 docs/reference/plugins-filters-cipher.md create mode 100644 docs/reference/plugins-filters-clone.md create mode 100644 docs/reference/plugins-filters-csv.md create mode 100644 docs/reference/plugins-filters-date.md create mode 100644 docs/reference/plugins-filters-de_dot.md create mode 100644 docs/reference/plugins-filters-dissect.md create mode 100644 docs/reference/plugins-filters-dns.md create mode 100644 docs/reference/plugins-filters-drop.md create mode 100644 docs/reference/plugins-filters-elapsed.md create mode 100644 docs/reference/plugins-filters-elastic_integration.md create mode 100644 docs/reference/plugins-filters-elasticsearch.md create mode 100644 docs/reference/plugins-filters-environment.md create mode 100644 docs/reference/plugins-filters-extractnumbers.md create mode 100644 docs/reference/plugins-filters-fingerprint.md create mode 100644 docs/reference/plugins-filters-geoip.md create mode 100644 docs/reference/plugins-filters-grok.md create mode 100644 docs/reference/plugins-filters-http.md create mode 100644 docs/reference/plugins-filters-i18n.md create mode 100644 docs/reference/plugins-filters-java_uuid.md create mode 100644 docs/reference/plugins-filters-jdbc_static.md create mode 100644 docs/reference/plugins-filters-jdbc_streaming.md create mode 100644 docs/reference/plugins-filters-json.md create mode 100644 docs/reference/plugins-filters-json_encode.md create mode 100644 docs/reference/plugins-filters-kv.md create mode 100644 docs/reference/plugins-filters-memcached.md create mode 100644 docs/reference/plugins-filters-metricize.md create mode 100644 docs/reference/plugins-filters-metrics.md create mode 100644 docs/reference/plugins-filters-mutate.md create mode 100644 docs/reference/plugins-filters-prune.md create mode 100644 docs/reference/plugins-filters-range.md create mode 100644 docs/reference/plugins-filters-ruby.md create mode 100644 docs/reference/plugins-filters-sleep.md create mode 100644 docs/reference/plugins-filters-split.md create mode 100644 docs/reference/plugins-filters-syslog_pri.md create mode 100644 docs/reference/plugins-filters-threats_classifier.md create mode 100644 docs/reference/plugins-filters-throttle.md create mode 100644 docs/reference/plugins-filters-tld.md create mode 100644 docs/reference/plugins-filters-translate.md create mode 100644 docs/reference/plugins-filters-truncate.md create mode 100644 docs/reference/plugins-filters-urldecode.md create mode 100644 docs/reference/plugins-filters-useragent.md create mode 100644 docs/reference/plugins-filters-uuid.md create mode 100644 docs/reference/plugins-filters-wurfl_device_detection.md create mode 100644 docs/reference/plugins-filters-xml.md create mode 100644 docs/reference/plugins-inputs-azure_event_hubs.md create mode 100644 docs/reference/plugins-inputs-beats.md create mode 100644 docs/reference/plugins-inputs-cloudwatch.md create mode 100644 docs/reference/plugins-inputs-couchdb_changes.md create mode 100644 docs/reference/plugins-inputs-dead_letter_queue.md create mode 100644 docs/reference/plugins-inputs-elastic_agent.md create mode 100644 docs/reference/plugins-inputs-elastic_serverless_forwarder.md create mode 100644 docs/reference/plugins-inputs-elasticsearch.md create mode 100644 docs/reference/plugins-inputs-exec.md create mode 100644 docs/reference/plugins-inputs-file.md create mode 100644 docs/reference/plugins-inputs-ganglia.md create mode 100644 docs/reference/plugins-inputs-gelf.md create mode 100644 docs/reference/plugins-inputs-generator.md create mode 100644 docs/reference/plugins-inputs-github.md create mode 100644 docs/reference/plugins-inputs-google_cloud_storage.md create mode 100644 docs/reference/plugins-inputs-google_pubsub.md create mode 100644 docs/reference/plugins-inputs-graphite.md create mode 100644 docs/reference/plugins-inputs-heartbeat.md create mode 100644 docs/reference/plugins-inputs-http.md create mode 100644 docs/reference/plugins-inputs-http_poller.md create mode 100644 docs/reference/plugins-inputs-imap.md create mode 100644 docs/reference/plugins-inputs-irc.md create mode 100644 docs/reference/plugins-inputs-java_generator.md create mode 100644 docs/reference/plugins-inputs-java_stdin.md create mode 100644 docs/reference/plugins-inputs-jdbc.md create mode 100644 docs/reference/plugins-inputs-jms.md create mode 100644 docs/reference/plugins-inputs-jmx.md create mode 100644 docs/reference/plugins-inputs-kafka.md create mode 100644 docs/reference/plugins-inputs-kinesis.md create mode 100644 docs/reference/plugins-inputs-log4j.md create mode 100644 docs/reference/plugins-inputs-logstash.md create mode 100644 docs/reference/plugins-inputs-lumberjack.md create mode 100644 docs/reference/plugins-inputs-meetup.md create mode 100644 docs/reference/plugins-inputs-pipe.md create mode 100644 docs/reference/plugins-inputs-puppet_facter.md create mode 100644 docs/reference/plugins-inputs-rabbitmq.md create mode 100644 docs/reference/plugins-inputs-redis.md create mode 100644 docs/reference/plugins-inputs-relp.md create mode 100644 docs/reference/plugins-inputs-rss.md create mode 100644 docs/reference/plugins-inputs-s3-sns-sqs.md create mode 100644 docs/reference/plugins-inputs-s3.md create mode 100644 docs/reference/plugins-inputs-salesforce.md create mode 100644 docs/reference/plugins-inputs-snmp.md create mode 100644 docs/reference/plugins-inputs-snmptrap.md create mode 100644 docs/reference/plugins-inputs-sqlite.md create mode 100644 docs/reference/plugins-inputs-sqs.md create mode 100644 docs/reference/plugins-inputs-stdin.md create mode 100644 docs/reference/plugins-inputs-stomp.md create mode 100644 docs/reference/plugins-inputs-syslog.md create mode 100644 docs/reference/plugins-inputs-tcp.md create mode 100644 docs/reference/plugins-inputs-twitter.md create mode 100644 docs/reference/plugins-inputs-udp.md create mode 100644 docs/reference/plugins-inputs-unix.md create mode 100644 docs/reference/plugins-inputs-varnishlog.md create mode 100644 docs/reference/plugins-inputs-websocket.md create mode 100644 docs/reference/plugins-inputs-wmi.md create mode 100644 docs/reference/plugins-inputs-xmpp.md create mode 100644 docs/reference/plugins-integrations-aws.md create mode 100644 docs/reference/plugins-integrations-elastic_enterprise_search.md create mode 100644 docs/reference/plugins-integrations-jdbc.md create mode 100644 docs/reference/plugins-integrations-kafka.md create mode 100644 docs/reference/plugins-integrations-logstash.md create mode 100644 docs/reference/plugins-integrations-rabbitmq.md create mode 100644 docs/reference/plugins-integrations-snmp.md create mode 100644 docs/reference/plugins-outputs-boundary.md create mode 100644 docs/reference/plugins-outputs-circonus.md create mode 100644 docs/reference/plugins-outputs-cloudwatch.md create mode 100644 docs/reference/plugins-outputs-csv.md create mode 100644 docs/reference/plugins-outputs-datadog.md create mode 100644 docs/reference/plugins-outputs-datadog_metrics.md create mode 100644 docs/reference/plugins-outputs-dynatrace.md create mode 100644 docs/reference/plugins-outputs-elastic_app_search.md create mode 100644 docs/reference/plugins-outputs-elastic_workplace_search.md create mode 100644 docs/reference/plugins-outputs-elasticsearch.md create mode 100644 docs/reference/plugins-outputs-email.md create mode 100644 docs/reference/plugins-outputs-exec.md create mode 100644 docs/reference/plugins-outputs-file.md create mode 100644 docs/reference/plugins-outputs-ganglia.md create mode 100644 docs/reference/plugins-outputs-gelf.md create mode 100644 docs/reference/plugins-outputs-google_bigquery.md create mode 100644 docs/reference/plugins-outputs-google_cloud_storage.md create mode 100644 docs/reference/plugins-outputs-google_pubsub.md create mode 100644 docs/reference/plugins-outputs-graphite.md create mode 100644 docs/reference/plugins-outputs-graphtastic.md create mode 100644 docs/reference/plugins-outputs-http.md create mode 100644 docs/reference/plugins-outputs-influxdb.md create mode 100644 docs/reference/plugins-outputs-irc.md create mode 100644 docs/reference/plugins-outputs-java_stdout.md create mode 100644 docs/reference/plugins-outputs-juggernaut.md create mode 100644 docs/reference/plugins-outputs-kafka.md create mode 100644 docs/reference/plugins-outputs-librato.md create mode 100644 docs/reference/plugins-outputs-loggly.md create mode 100644 docs/reference/plugins-outputs-logstash.md create mode 100644 docs/reference/plugins-outputs-lumberjack.md create mode 100644 docs/reference/plugins-outputs-metriccatcher.md create mode 100644 docs/reference/plugins-outputs-mongodb.md create mode 100644 docs/reference/plugins-outputs-nagios.md create mode 100644 docs/reference/plugins-outputs-nagios_nsca.md create mode 100644 docs/reference/plugins-outputs-opentsdb.md create mode 100644 docs/reference/plugins-outputs-pagerduty.md create mode 100644 docs/reference/plugins-outputs-pipe.md create mode 100644 docs/reference/plugins-outputs-rabbitmq.md create mode 100644 docs/reference/plugins-outputs-redis.md create mode 100644 docs/reference/plugins-outputs-redmine.md create mode 100644 docs/reference/plugins-outputs-riak.md create mode 100644 docs/reference/plugins-outputs-riemann.md create mode 100644 docs/reference/plugins-outputs-s3.md create mode 100644 docs/reference/plugins-outputs-sink.md create mode 100644 docs/reference/plugins-outputs-sns.md create mode 100644 docs/reference/plugins-outputs-solr_http.md create mode 100644 docs/reference/plugins-outputs-sqs.md create mode 100644 docs/reference/plugins-outputs-statsd.md create mode 100644 docs/reference/plugins-outputs-stdout.md create mode 100644 docs/reference/plugins-outputs-stomp.md create mode 100644 docs/reference/plugins-outputs-syslog.md create mode 100644 docs/reference/plugins-outputs-tcp.md create mode 100644 docs/reference/plugins-outputs-timber.md create mode 100644 docs/reference/plugins-outputs-udp.md create mode 100644 docs/reference/plugins-outputs-webhdfs.md create mode 100644 docs/reference/plugins-outputs-websocket.md create mode 100644 docs/reference/plugins-outputs-xmpp.md create mode 100644 docs/reference/plugins-outputs-zabbix.md create mode 100644 docs/reference/private-rubygem.md create mode 100644 docs/reference/processing.md create mode 100644 docs/reference/queues-data-resiliency.md create mode 100644 docs/reference/reloading-config.md create mode 100644 docs/reference/running-logstash-command-line.md create mode 100644 docs/reference/running-logstash-kubernetes.md create mode 100644 docs/reference/running-logstash-windows.md create mode 100644 docs/reference/running-logstash.md create mode 100644 docs/reference/secure-connection.md create mode 100644 docs/reference/serverless-monitoring-with-elastic-agent.md create mode 100644 docs/reference/setting-up-running-logstash.md rename docs/{static/shutdown.asciidoc => reference/shutdown.md} (56%) create mode 100644 docs/reference/tips-best-practices.md create mode 100644 docs/reference/toc.yml create mode 100644 docs/reference/transforming-data.md create mode 100644 docs/reference/tuning-logstash.md create mode 100644 docs/reference/upgrading-logstash-9-0.md create mode 100644 docs/reference/upgrading-logstash.md create mode 100644 docs/reference/upgrading-minor-versions.md create mode 100644 docs/reference/upgrading-using-direct-download.md create mode 100644 docs/reference/upgrading-using-package-managers.md create mode 100644 docs/reference/use-filebeat-modules-kafka.md create mode 100644 docs/reference/use-ingest-pipelines.md create mode 100644 docs/reference/using-logstash-with-elastic-integrations.md create mode 100644 docs/reference/working-with-filebeat-modules.md create mode 100644 docs/reference/working-with-plugins.md create mode 100644 docs/reference/working-with-winlogbeat-modules.md create mode 100644 docs/release-notes/breaking-changes.md create mode 100644 docs/release-notes/deprecations.md create mode 100644 docs/release-notes/index.md create mode 100644 docs/release-notes/known-issues.md create mode 100644 docs/release-notes/toc.yml delete mode 100644 docs/static/advanced-pipeline.asciidoc delete mode 100644 docs/static/best-practice.asciidoc delete mode 100644 docs/static/breaking-changes-60.asciidoc delete mode 100644 docs/static/breaking-changes-70.asciidoc delete mode 100644 docs/static/breaking-changes-80.asciidoc delete mode 100644 docs/static/breaking-changes-90.asciidoc delete mode 100644 docs/static/breaking-changes.asciidoc delete mode 100644 docs/static/codec.asciidoc delete mode 100644 docs/static/config-details.asciidoc delete mode 100644 docs/static/config-management.asciidoc delete mode 100644 docs/static/configuration-advanced.asciidoc delete mode 100644 docs/static/contrib-acceptance.asciidoc delete mode 100644 docs/static/contribute-core.asciidoc delete mode 100644 docs/static/contributing-java-plugin.asciidoc delete mode 100644 docs/static/contributing-patch.asciidoc delete mode 100644 docs/static/contributing-to-logstash.asciidoc delete mode 100644 docs/static/core-plugins/codecs/java_dots.asciidoc delete mode 100644 docs/static/core-plugins/codecs/java_line.asciidoc delete mode 100644 docs/static/core-plugins/codecs/java_plain.asciidoc delete mode 100644 docs/static/core-plugins/filters/java_uuid.asciidoc delete mode 100644 docs/static/core-plugins/inputs/java_generator.asciidoc delete mode 100644 docs/static/core-plugins/inputs/java_stdin.asciidoc delete mode 100644 docs/static/core-plugins/outputs/java_sink.asciidoc delete mode 100644 docs/static/core-plugins/outputs/java_stdout.asciidoc delete mode 100644 docs/static/cross-plugin-concepts.asciidoc delete mode 100644 docs/static/dead-letter-queues.asciidoc delete mode 100644 docs/static/deploying.asciidoc delete mode 100644 docs/static/doc-for-plugin.asciidoc delete mode 100644 docs/static/docker.asciidoc delete mode 100644 docs/static/ea-integrations.asciidoc delete mode 100644 docs/static/ecs-compatibility.asciidoc delete mode 100644 docs/static/event-api.asciidoc delete mode 100644 docs/static/event-data.asciidoc delete mode 100644 docs/static/fb-ls-kafka-example.asciidoc delete mode 100644 docs/static/field-reference.asciidoc delete mode 100644 docs/static/filebeat-modules.asciidoc delete mode 100644 docs/static/filter.asciidoc delete mode 100644 docs/static/geoip-database-management.asciidoc delete mode 100644 docs/static/geoip-database-management/configuring.asciidoc delete mode 100644 docs/static/geoip-database-management/index.asciidoc delete mode 100644 docs/static/geoip-database-management/metrics.asciidoc delete mode 100644 docs/static/getting-started-with-logstash.asciidoc delete mode 100644 docs/static/glob-support.asciidoc delete mode 100644 docs/static/images/arcsight-diagram-adp.svg delete mode 100644 docs/static/images/arcsight-diagram-smart-connectors.svg delete mode 100644 docs/static/images/arcsight-network-overview.png delete mode 100644 docs/static/images/arcsight-network-suspicious.png delete mode 100644 docs/static/images/azure-flow.png delete mode 100644 docs/static/images/deploy_1.png delete mode 100644 docs/static/images/deploy_2.png delete mode 100644 docs/static/images/deploy_3.png delete mode 100644 docs/static/images/deploy_4.png delete mode 100644 docs/static/images/deploy_5.png delete mode 100644 docs/static/images/deploy_6.png delete mode 100644 docs/static/images/deploy_7.png delete mode 100644 docs/static/images/logstash-module-overview.png delete mode 100644 docs/static/images/logstash.png delete mode 100644 docs/static/images/netflow-conversation-partners.png delete mode 100644 docs/static/images/netflow-geo-location.png delete mode 100644 docs/static/images/netflow-overview.png delete mode 100644 docs/static/images/netflow-traffic-analysis.png delete mode 100644 docs/static/include/javapluginpkg.asciidoc delete mode 100644 docs/static/include/javapluginsetup.asciidoc delete mode 100644 docs/static/include/pluginbody.asciidoc delete mode 100644 docs/static/input.asciidoc delete mode 100644 docs/static/introduction.asciidoc delete mode 100644 docs/static/java-codec.asciidoc delete mode 100644 docs/static/java-filter.asciidoc delete mode 100644 docs/static/java-input.asciidoc delete mode 100644 docs/static/java-output.asciidoc delete mode 100644 docs/static/jvm.asciidoc delete mode 100644 docs/static/keystore.asciidoc delete mode 100644 docs/static/life-of-an-event.asciidoc delete mode 100644 docs/static/listing-a-plugin.asciidoc delete mode 100644 docs/static/logging.asciidoc delete mode 100644 docs/static/logstash-glossary.asciidoc delete mode 100644 docs/static/ls-ls-config.asciidoc delete mode 100644 docs/static/ls-ls-http.asciidoc delete mode 100644 docs/static/ls-ls-native.asciidoc delete mode 100644 docs/static/ls-to-cloud.asciidoc delete mode 100644 docs/static/maintainer-guide.asciidoc delete mode 100644 docs/static/management/centralized-pipelines.asciidoc delete mode 100644 docs/static/management/configuring-centralized-pipelines.asciidoc delete mode 100644 docs/static/management/images/new_pipeline.png delete mode 100644 docs/static/managing-multiline-events.asciidoc delete mode 100644 docs/static/mem-queue.asciidoc delete mode 100644 docs/static/monitoring/collectors-legacy.asciidoc delete mode 100644 docs/static/monitoring/images/integration-agent-add-standalone.png delete mode 100644 docs/static/monitoring/images/integration-agent-add.png delete mode 100644 docs/static/monitoring/images/integration-agent-confirm.png delete mode 100644 docs/static/monitoring/images/pipeline-diagram.png delete mode 100644 docs/static/monitoring/images/pipeline-filter-detail.png delete mode 100644 docs/static/monitoring/images/pipeline-output-detail.png delete mode 100644 docs/static/monitoring/images/pipeline-viewer-detail-drawer.png delete mode 100644 docs/static/monitoring/images/pipeline-viewer-overview.png delete mode 100644 docs/static/monitoring/monitoring-apis.asciidoc delete mode 100644 docs/static/monitoring/monitoring-ea-dashboards.asciidoc delete mode 100644 docs/static/monitoring/monitoring-ea-intro.asciidoc delete mode 100644 docs/static/monitoring/monitoring-ea-serverless.asciidoc delete mode 100644 docs/static/monitoring/monitoring-ea.asciidoc delete mode 100644 docs/static/monitoring/monitoring-install.asciidoc delete mode 100644 docs/static/monitoring/monitoring-internal-legacy.asciidoc delete mode 100644 docs/static/monitoring/monitoring-mb.asciidoc delete mode 100644 docs/static/monitoring/monitoring-output-legacy.asciidoc delete mode 100644 docs/static/monitoring/monitoring-overview.asciidoc delete mode 100644 docs/static/monitoring/monitoring-prereq-create-user.asciidoc delete mode 100644 docs/static/monitoring/monitoring-prereq-define-cluster.asciidoc delete mode 100644 docs/static/monitoring/monitoring-prereq-disable-default.asciidoc delete mode 100644 docs/static/monitoring/monitoring-prereq-setup-es.asciidoc delete mode 100644 docs/static/monitoring/monitoring-ui.asciidoc delete mode 100644 docs/static/monitoring/monitoring-view.asciidoc delete mode 100644 docs/static/monitoring/monitoring.asciidoc delete mode 100644 docs/static/monitoring/pipeline-viewer.asciidoc delete mode 100644 docs/static/monitoring/troubleshooting.asciidoc delete mode 100644 docs/static/offline-plugins.asciidoc delete mode 100644 docs/static/output.asciidoc delete mode 100644 docs/static/performance-checklist.asciidoc delete mode 100644 docs/static/persistent-queues.asciidoc delete mode 100644 docs/static/pipeline-configuration.asciidoc delete mode 100644 docs/static/pipeline-structure.asciidoc delete mode 100644 docs/static/plugin-generator.asciidoc delete mode 100644 docs/static/plugin-manager.asciidoc delete mode 100644 docs/static/private-gem-repo.asciidoc delete mode 100644 docs/static/processing-info.asciidoc delete mode 100644 docs/static/redirects.asciidoc delete mode 100644 docs/static/releasenotes.asciidoc delete mode 100644 docs/static/reloading-config.asciidoc delete mode 100644 docs/static/reserved-fields.asciidoc delete mode 100644 docs/static/resiliency.asciidoc delete mode 100644 docs/static/running-logstash-command-line.asciidoc delete mode 100644 docs/static/running-logstash-kubernetes.asciidoc delete mode 100644 docs/static/running-logstash-windows.asciidoc delete mode 100644 docs/static/running-logstash.asciidoc delete mode 100644 docs/static/security/api-keys.asciidoc delete mode 100644 docs/static/security/basic-auth.asciidoc delete mode 100644 docs/static/security/es-security.asciidoc delete mode 100644 docs/static/security/grant-access.asciidoc delete mode 100644 docs/static/security/logstash.asciidoc delete mode 100644 docs/static/security/ls-monitoring.asciidoc delete mode 100644 docs/static/security/pipeline-mgmt.asciidoc delete mode 100644 docs/static/security/pki-auth.asciidoc delete mode 100644 docs/static/security/tls-encryption.asciidoc delete mode 100644 docs/static/setting-up-logstash.asciidoc delete mode 100644 docs/static/settings-file.asciidoc delete mode 100644 docs/static/settings/configuration-management-settings.asciidoc delete mode 100644 docs/static/settings/configuration-wildcard-pipeline-id.asciidoc delete mode 100644 docs/static/settings/geoip-database-management-settings.asciidoc delete mode 100644 docs/static/settings/monitoring-settings-legacy.asciidoc delete mode 100644 docs/static/submitting-a-plugin.asciidoc delete mode 100644 docs/static/tab-widgets/install-agent-widget.asciidoc delete mode 100644 docs/static/tab-widgets/install-agent.asciidoc delete mode 100644 docs/static/transforming-data.asciidoc delete mode 100644 docs/static/troubleshoot/health-pipeline-flow-worker-utilization.asciidoc delete mode 100644 docs/static/troubleshoot/health-pipeline-status.asciidoc delete mode 100644 docs/static/troubleshoot/plugin-tracing.asciidoc delete mode 100644 docs/static/troubleshoot/troubleshooting.asciidoc delete mode 100644 docs/static/troubleshoot/ts-azure.asciidoc delete mode 100644 docs/static/troubleshoot/ts-kafka.asciidoc delete mode 100644 docs/static/troubleshoot/ts-logstash.asciidoc delete mode 100644 docs/static/troubleshoot/ts-other-issues.asciidoc delete mode 100644 docs/static/troubleshoot/ts-plugins-general.asciidoc delete mode 100644 docs/static/troubleshoot/ts-plugins.asciidoc delete mode 100644 docs/static/upgrading.asciidoc delete mode 100644 docs/static/winlogbeat-modules.asciidoc diff --git a/docs/docset.yml b/docs/docset.yml new file mode 100644 index 000000000..e48937257 --- /dev/null +++ b/docs/docset.yml @@ -0,0 +1,493 @@ +project: 'Logstash' +cross_links: + - beats + - docs-content + - ecs + - elasticsearch + - integration-docs + - logstash-docs + - search-ui +toc: + - toc: reference + - toc: release-notes + - toc: extend +subs: + ref: "https://www.elastic.co/guide/en/elasticsearch/reference/current" + ref-bare: "https://www.elastic.co/guide/en/elasticsearch/reference" + ref-8x: "https://www.elastic.co/guide/en/elasticsearch/reference/8.1" + ref-80: "https://www.elastic.co/guide/en/elasticsearch/reference/8.0" + ref-7x: "https://www.elastic.co/guide/en/elasticsearch/reference/7.17" + ref-70: "https://www.elastic.co/guide/en/elasticsearch/reference/7.0" + ref-60: "https://www.elastic.co/guide/en/elasticsearch/reference/6.0" + ref-64: "https://www.elastic.co/guide/en/elasticsearch/reference/6.4" + xpack-ref: "https://www.elastic.co/guide/en/x-pack/6.2" + logstash-ref: "https://www.elastic.co/guide/en/logstash/current" + kibana-ref: "https://www.elastic.co/guide/en/kibana/current" + kibana-ref-all: "https://www.elastic.co/guide/en/kibana" + beats-ref-root: "https://www.elastic.co/guide/en/beats" + beats-ref: "https://www.elastic.co/guide/en/beats/libbeat/current" + beats-ref-60: "https://www.elastic.co/guide/en/beats/libbeat/6.0" + beats-ref-63: "https://www.elastic.co/guide/en/beats/libbeat/6.3" + beats-devguide: "https://www.elastic.co/guide/en/beats/devguide/current" + auditbeat-ref: "https://www.elastic.co/guide/en/beats/auditbeat/current" + packetbeat-ref: "https://www.elastic.co/guide/en/beats/packetbeat/current" + metricbeat-ref: "https://www.elastic.co/guide/en/beats/metricbeat/current" + filebeat-ref: "https://www.elastic.co/guide/en/beats/filebeat/current" + functionbeat-ref: "https://www.elastic.co/guide/en/beats/functionbeat/current" + winlogbeat-ref: "https://www.elastic.co/guide/en/beats/winlogbeat/current" + heartbeat-ref: "https://www.elastic.co/guide/en/beats/heartbeat/current" + journalbeat-ref: "https://www.elastic.co/guide/en/beats/journalbeat/current" + ingest-guide: "https://www.elastic.co/guide/en/ingest/current" + fleet-guide: "https://www.elastic.co/guide/en/fleet/current" + apm-guide-ref: "https://www.elastic.co/guide/en/apm/guide/current" + apm-guide-7x: "https://www.elastic.co/guide/en/apm/guide/7.17" + apm-app-ref: "https://www.elastic.co/guide/en/kibana/current" + apm-agents-ref: "https://www.elastic.co/guide/en/apm/agent" + apm-android-ref: "https://www.elastic.co/guide/en/apm/agent/android/current" + apm-py-ref: "https://www.elastic.co/guide/en/apm/agent/python/current" + apm-py-ref-3x: "https://www.elastic.co/guide/en/apm/agent/python/3.x" + apm-node-ref-index: "https://www.elastic.co/guide/en/apm/agent/nodejs" + apm-node-ref: "https://www.elastic.co/guide/en/apm/agent/nodejs/current" + apm-node-ref-1x: "https://www.elastic.co/guide/en/apm/agent/nodejs/1.x" + apm-rum-ref: "https://www.elastic.co/guide/en/apm/agent/rum-js/current" + apm-ruby-ref: "https://www.elastic.co/guide/en/apm/agent/ruby/current" + apm-java-ref: "https://www.elastic.co/guide/en/apm/agent/java/current" + apm-go-ref: "https://www.elastic.co/guide/en/apm/agent/go/current" + apm-dotnet-ref: "https://www.elastic.co/guide/en/apm/agent/dotnet/current" + apm-php-ref: "https://www.elastic.co/guide/en/apm/agent/php/current" + apm-ios-ref: "https://www.elastic.co/guide/en/apm/agent/swift/current" + apm-lambda-ref: "https://www.elastic.co/guide/en/apm/lambda/current" + apm-attacher-ref: "https://www.elastic.co/guide/en/apm/attacher/current" + docker-logging-ref: "https://www.elastic.co/guide/en/beats/loggingplugin/current" + esf-ref: "https://www.elastic.co/guide/en/esf/current" + kinesis-firehose-ref: "https://www.elastic.co/guide/en/kinesis/{{kinesis_version}}" + estc-welcome-current: "https://www.elastic.co/guide/en/starting-with-the-elasticsearch-platform-and-its-solutions/current" + estc-welcome: "https://www.elastic.co/guide/en/starting-with-the-elasticsearch-platform-and-its-solutions/current" + estc-welcome-all: "https://www.elastic.co/guide/en/starting-with-the-elasticsearch-platform-and-its-solutions" + hadoop-ref: "https://www.elastic.co/guide/en/elasticsearch/hadoop/current" + stack-ref: "https://www.elastic.co/guide/en/elastic-stack/current" + stack-ref-67: "https://www.elastic.co/guide/en/elastic-stack/6.7" + stack-ref-68: "https://www.elastic.co/guide/en/elastic-stack/6.8" + stack-ref-70: "https://www.elastic.co/guide/en/elastic-stack/7.0" + stack-ref-80: "https://www.elastic.co/guide/en/elastic-stack/8.0" + stack-ov: "https://www.elastic.co/guide/en/elastic-stack-overview/current" + stack-gs: "https://www.elastic.co/guide/en/elastic-stack-get-started/current" + stack-gs-current: "https://www.elastic.co/guide/en/elastic-stack-get-started/current" + javaclient: "https://www.elastic.co/guide/en/elasticsearch/client/java-api/current" + java-api-client: "https://www.elastic.co/guide/en/elasticsearch/client/java-api-client/current" + java-rest: "https://www.elastic.co/guide/en/elasticsearch/client/java-rest/current" + jsclient: "https://www.elastic.co/guide/en/elasticsearch/client/javascript-api/current" + jsclient-current: "https://www.elastic.co/guide/en/elasticsearch/client/javascript-api/current" + es-ruby-client: "https://www.elastic.co/guide/en/elasticsearch/client/ruby-api/current" + es-dotnet-client: "https://www.elastic.co/guide/en/elasticsearch/client/net-api/current" + es-php-client: "https://www.elastic.co/guide/en/elasticsearch/client/php-api/current" + es-python-client: "https://www.elastic.co/guide/en/elasticsearch/client/python-api/current" + defguide: "https://www.elastic.co/guide/en/elasticsearch/guide/2.x" + painless: "https://www.elastic.co/guide/en/elasticsearch/painless/current" + plugins: "https://www.elastic.co/guide/en/elasticsearch/plugins/current" + plugins-8x: "https://www.elastic.co/guide/en/elasticsearch/plugins/8.1" + plugins-7x: "https://www.elastic.co/guide/en/elasticsearch/plugins/7.17" + plugins-6x: "https://www.elastic.co/guide/en/elasticsearch/plugins/6.8" + glossary: "https://www.elastic.co/guide/en/elastic-stack-glossary/current" + upgrade_guide: "https://www.elastic.co/products/upgrade_guide" + blog-ref: "https://www.elastic.co/blog/" + curator-ref: "https://www.elastic.co/guide/en/elasticsearch/client/curator/current" + curator-ref-current: "https://www.elastic.co/guide/en/elasticsearch/client/curator/current" + metrics-ref: "https://www.elastic.co/guide/en/metrics/current" + metrics-guide: "https://www.elastic.co/guide/en/metrics/guide/current" + logs-ref: "https://www.elastic.co/guide/en/logs/current" + logs-guide: "https://www.elastic.co/guide/en/logs/guide/current" + uptime-guide: "https://www.elastic.co/guide/en/uptime/current" + observability-guide: "https://www.elastic.co/guide/en/observability/current" + observability-guide-all: "https://www.elastic.co/guide/en/observability" + siem-guide: "https://www.elastic.co/guide/en/siem/guide/current" + security-guide: "https://www.elastic.co/guide/en/security/current" + security-guide-all: "https://www.elastic.co/guide/en/security" + endpoint-guide: "https://www.elastic.co/guide/en/endpoint/current" + sql-odbc: "https://www.elastic.co/guide/en/elasticsearch/sql-odbc/current" + ecs-ref: "https://www.elastic.co/guide/en/ecs/current" + ecs-logging-ref: "https://www.elastic.co/guide/en/ecs-logging/overview/current" + ecs-logging-go-logrus-ref: "https://www.elastic.co/guide/en/ecs-logging/go-logrus/current" + ecs-logging-go-zap-ref: "https://www.elastic.co/guide/en/ecs-logging/go-zap/current" + ecs-logging-go-zerolog-ref: "https://www.elastic.co/guide/en/ecs-logging/go-zap/current" + ecs-logging-java-ref: "https://www.elastic.co/guide/en/ecs-logging/java/current" + ecs-logging-dotnet-ref: "https://www.elastic.co/guide/en/ecs-logging/dotnet/current" + ecs-logging-nodejs-ref: "https://www.elastic.co/guide/en/ecs-logging/nodejs/current" + ecs-logging-php-ref: "https://www.elastic.co/guide/en/ecs-logging/php/current" + ecs-logging-python-ref: "https://www.elastic.co/guide/en/ecs-logging/python/current" + ecs-logging-ruby-ref: "https://www.elastic.co/guide/en/ecs-logging/ruby/current" + ml-docs: "https://www.elastic.co/guide/en/machine-learning/current" + eland-docs: "https://www.elastic.co/guide/en/elasticsearch/client/eland/current" + eql-ref: "https://eql.readthedocs.io/en/latest/query-guide" + extendtrial: "https://www.elastic.co/trialextension" + wikipedia: "https://en.wikipedia.org/wiki" + forum: "https://discuss.elastic.co/" + xpack-forum: "https://discuss.elastic.co/c/50-x-pack" + security-forum: "https://discuss.elastic.co/c/x-pack/shield" + watcher-forum: "https://discuss.elastic.co/c/x-pack/watcher" + monitoring-forum: "https://discuss.elastic.co/c/x-pack/marvel" + graph-forum: "https://discuss.elastic.co/c/x-pack/graph" + apm-forum: "https://discuss.elastic.co/c/apm" + enterprise-search-ref: "https://www.elastic.co/guide/en/enterprise-search/current" + app-search-ref: "https://www.elastic.co/guide/en/app-search/current" + workplace-search-ref: "https://www.elastic.co/guide/en/workplace-search/current" + enterprise-search-node-ref: "https://www.elastic.co/guide/en/enterprise-search-clients/enterprise-search-node/current" + enterprise-search-php-ref: "https://www.elastic.co/guide/en/enterprise-search-clients/php/current" + enterprise-search-python-ref: "https://www.elastic.co/guide/en/enterprise-search-clients/python/current" + enterprise-search-ruby-ref: "https://www.elastic.co/guide/en/enterprise-search-clients/ruby/current" + elastic-maps-service: "https://maps.elastic.co" + integrations-docs: "https://docs.elastic.co/en/integrations" + integrations-devguide: "https://www.elastic.co/guide/en/integrations-developer/current" + time-units: "https://www.elastic.co/guide/en/elasticsearch/reference/current/api-conventions.html#time-units" + byte-units: "https://www.elastic.co/guide/en/elasticsearch/reference/current/api-conventions.html#byte-units" + apm-py-ref-v: "https://www.elastic.co/guide/en/apm/agent/python/current" + apm-node-ref-v: "https://www.elastic.co/guide/en/apm/agent/nodejs/current" + apm-rum-ref-v: "https://www.elastic.co/guide/en/apm/agent/rum-js/current" + apm-ruby-ref-v: "https://www.elastic.co/guide/en/apm/agent/ruby/current" + apm-java-ref-v: "https://www.elastic.co/guide/en/apm/agent/java/current" + apm-go-ref-v: "https://www.elastic.co/guide/en/apm/agent/go/current" + apm-ios-ref-v: "https://www.elastic.co/guide/en/apm/agent/swift/current" + apm-dotnet-ref-v: "https://www.elastic.co/guide/en/apm/agent/dotnet/current" + apm-php-ref-v: "https://www.elastic.co/guide/en/apm/agent/php/current" + ecloud: "Elastic Cloud" + esf: "Elastic Serverless Forwarder" + ess: "Elasticsearch Service" + ece: "Elastic Cloud Enterprise" + eck: "Elastic Cloud on Kubernetes" + serverless-full: "Elastic Cloud Serverless" + serverless-short: "Serverless" + es-serverless: "Elasticsearch Serverless" + es3: "Elasticsearch Serverless" + obs-serverless: "Elastic Observability Serverless" + sec-serverless: "Elastic Security Serverless" + serverless-docs: "https://docs.elastic.co/serverless" + cloud: "https://www.elastic.co/guide/en/cloud/current" + ess-utm-params: "?page=docs&placement=docs-body" + ess-baymax: "?page=docs&placement=docs-body" + ess-trial: "https://cloud.elastic.co/registration?page=docs&placement=docs-body" + ess-product: "https://www.elastic.co/cloud/elasticsearch-service?page=docs&placement=docs-body" + ess-console: "https://cloud.elastic.co?page=docs&placement=docs-body" + ess-console-name: "Elasticsearch Service Console" + ess-deployments: "https://cloud.elastic.co/deployments?page=docs&placement=docs-body" + ece-ref: "https://www.elastic.co/guide/en/cloud-enterprise/current" + eck-ref: "https://www.elastic.co/guide/en/cloud-on-k8s/current" + ess-leadin: "You can run Elasticsearch on your own hardware or use our hosted Elasticsearch Service that is available on AWS, GCP, and Azure. https://cloud.elastic.co/registration{ess-utm-params}[Try the Elasticsearch Service for free]." + ess-leadin-short: "Our hosted Elasticsearch Service is available on AWS, GCP, and Azure, and you can https://cloud.elastic.co/registration{ess-utm-params}[try it for free]." + ess-icon: "image:https://doc-icons.s3.us-east-2.amazonaws.com/logo_cloud.svg[link=\"https://cloud.elastic.co/registration{ess-utm-params}\", title=\"Supported on Elasticsearch Service\"]" + ece-icon: "image:https://doc-icons.s3.us-east-2.amazonaws.com/logo_cloud_ece.svg[link=\"https://cloud.elastic.co/registration{ess-utm-params}\", title=\"Supported on Elastic Cloud Enterprise\"]" + cloud-only: "This feature is designed for indirect use by https://cloud.elastic.co/registration{ess-utm-params}[Elasticsearch Service], https://www.elastic.co/guide/en/cloud-enterprise/{ece-version-link}[Elastic Cloud Enterprise], and https://www.elastic.co/guide/en/cloud-on-k8s/current[Elastic Cloud on Kubernetes]. Direct use is not supported." + ess-setting-change: "image:https://doc-icons.s3.us-east-2.amazonaws.com/logo_cloud.svg[link=\"{ess-trial}\", title=\"Supported on {ess}\"] indicates a change to a supported https://www.elastic.co/guide/en/cloud/current/ec-add-user-settings.html[user setting] for Elasticsearch Service." + ess-skip-section: "If you use Elasticsearch Service, skip this section. Elasticsearch Service handles these changes for you." + api-cloud: "https://www.elastic.co/docs/api/doc/cloud" + api-ece: "https://www.elastic.co/docs/api/doc/cloud-enterprise" + api-kibana-serverless: "https://www.elastic.co/docs/api/doc/serverless" + es-feature-flag: "This feature is in development and not yet available for use. This documentation is provided for informational purposes only." + es-ref-dir: "'{{elasticsearch-root}}/docs/reference'" + apm-app: "APM app" + uptime-app: "Uptime app" + synthetics-app: "Synthetics app" + logs-app: "Logs app" + metrics-app: "Metrics app" + infrastructure-app: "Infrastructure app" + siem-app: "SIEM app" + security-app: "Elastic Security app" + ml-app: "Machine Learning" + dev-tools-app: "Dev Tools" + ingest-manager-app: "Ingest Manager" + stack-manage-app: "Stack Management" + stack-monitor-app: "Stack Monitoring" + alerts-ui: "Alerts and Actions" + rules-ui: "Rules" + rac-ui: "Rules and Connectors" + connectors-ui: "Connectors" + connectors-feature: "Actions and Connectors" + stack-rules-feature: "Stack Rules" + user-experience: "User Experience" + ems: "Elastic Maps Service" + ems-init: "EMS" + hosted-ems: "Elastic Maps Server" + ipm-app: "Index Pattern Management" + ingest-pipelines: "ingest pipelines" + ingest-pipelines-app: "Ingest Pipelines" + ingest-pipelines-cap: "Ingest pipelines" + ls-pipelines: "Logstash pipelines" + ls-pipelines-app: "Logstash Pipelines" + maint-windows: "maintenance windows" + maint-windows-app: "Maintenance Windows" + maint-windows-cap: "Maintenance windows" + custom-roles-app: "Custom Roles" + data-source: "data view" + data-sources: "data views" + data-source-caps: "Data View" + data-sources-caps: "Data Views" + data-source-cap: "Data view" + data-sources-cap: "Data views" + project-settings: "Project settings" + manage-app: "Management" + index-manage-app: "Index Management" + data-views-app: "Data Views" + rules-app: "Rules" + saved-objects-app: "Saved Objects" + tags-app: "Tags" + api-keys-app: "API keys" + transforms-app: "Transforms" + connectors-app: "Connectors" + files-app: "Files" + reports-app: "Reports" + maps-app: "Maps" + alerts-app: "Alerts" + crawler: "Enterprise Search web crawler" + ents: "Enterprise Search" + app-search-crawler: "App Search web crawler" + agent: "Elastic Agent" + agents: "Elastic Agents" + fleet: "Fleet" + fleet-server: "Fleet Server" + integrations-server: "Integrations Server" + ingest-manager: "Ingest Manager" + ingest-management: "ingest management" + package-manager: "Elastic Package Manager" + integrations: "Integrations" + package-registry: "Elastic Package Registry" + artifact-registry: "Elastic Artifact Registry" + aws: "AWS" + stack: "Elastic Stack" + xpack: "X-Pack" + es: "Elasticsearch" + kib: "Kibana" + esms: "Elastic Stack Monitoring Service" + esms-init: "ESMS" + ls: "Logstash" + beats: "Beats" + auditbeat: "Auditbeat" + filebeat: "Filebeat" + heartbeat: "Heartbeat" + metricbeat: "Metricbeat" + packetbeat: "Packetbeat" + winlogbeat: "Winlogbeat" + functionbeat: "Functionbeat" + journalbeat: "Journalbeat" + es-sql: "Elasticsearch SQL" + esql: "ES|QL" + elastic-agent: "Elastic Agent" + k8s: "Kubernetes" + log-driver-long: "Elastic Logging Plugin for Docker" + security: "X-Pack security" + security-features: "security features" + operator-feature: "operator privileges feature" + es-security-features: "Elasticsearch security features" + stack-security-features: "Elastic Stack security features" + endpoint-sec: "Endpoint Security" + endpoint-cloud-sec: "Endpoint and Cloud Security" + elastic-defend: "Elastic Defend" + elastic-sec: "Elastic Security" + elastic-endpoint: "Elastic Endpoint" + swimlane: "Swimlane" + sn: "ServiceNow" + sn-itsm: "ServiceNow ITSM" + sn-itom: "ServiceNow ITOM" + sn-sir: "ServiceNow SecOps" + jira: "Jira" + ibm-r: "IBM Resilient" + webhook: "Webhook" + webhook-cm: "Webhook - Case Management" + opsgenie: "Opsgenie" + bedrock: "Amazon Bedrock" + gemini: "Google Gemini" + hive: "TheHive" + monitoring: "X-Pack monitoring" + monitor-features: "monitoring features" + stack-monitor-features: "Elastic Stack monitoring features" + watcher: "Watcher" + alert-features: "alerting features" + reporting: "X-Pack reporting" + report-features: "reporting features" + graph: "X-Pack graph" + graph-features: "graph analytics features" + searchprofiler: "Search Profiler" + xpackml: "X-Pack machine learning" + ml: "machine learning" + ml-cap: "Machine learning" + ml-init: "ML" + ml-features: "machine learning features" + stack-ml-features: "Elastic Stack machine learning features" + ccr: "cross-cluster replication" + ccr-cap: "Cross-cluster replication" + ccr-init: "CCR" + ccs: "cross-cluster search" + ccs-cap: "Cross-cluster search" + ccs-init: "CCS" + ilm: "index lifecycle management" + ilm-cap: "Index lifecycle management" + ilm-init: "ILM" + dlm: "data lifecycle management" + dlm-cap: "Data lifecycle management" + dlm-init: "DLM" + search-snap: "searchable snapshot" + search-snaps: "searchable snapshots" + search-snaps-cap: "Searchable snapshots" + slm: "snapshot lifecycle management" + slm-cap: "Snapshot lifecycle management" + slm-init: "SLM" + rollup-features: "data rollup features" + ipm: "index pattern management" + ipm-cap: "Index pattern" + rollup: "rollup" + rollup-cap: "Rollup" + rollups: "rollups" + rollups-cap: "Rollups" + rollup-job: "rollup job" + rollup-jobs: "rollup jobs" + rollup-jobs-cap: "Rollup jobs" + dfeed: "datafeed" + dfeeds: "datafeeds" + dfeed-cap: "Datafeed" + dfeeds-cap: "Datafeeds" + ml-jobs: "machine learning jobs" + ml-jobs-cap: "Machine learning jobs" + anomaly-detect: "anomaly detection" + anomaly-detect-cap: "Anomaly detection" + anomaly-job: "anomaly detection job" + anomaly-jobs: "anomaly detection jobs" + anomaly-jobs-cap: "Anomaly detection jobs" + dataframe: "data frame" + dataframes: "data frames" + dataframe-cap: "Data frame" + dataframes-cap: "Data frames" + watcher-transform: "payload transform" + watcher-transforms: "payload transforms" + watcher-transform-cap: "Payload transform" + watcher-transforms-cap: "Payload transforms" + transform: "transform" + transforms: "transforms" + transform-cap: "Transform" + transforms-cap: "Transforms" + dataframe-transform: "transform" + dataframe-transform-cap: "Transform" + dataframe-transforms: "transforms" + dataframe-transforms-cap: "Transforms" + dfanalytics-cap: "Data frame analytics" + dfanalytics: "data frame analytics" + dataframe-analytics-config: "'{dataframe} analytics config'" + dfanalytics-job: "'{dataframe} analytics job'" + dfanalytics-jobs: "'{dataframe} analytics jobs'" + dfanalytics-jobs-cap: "'{dataframe-cap} analytics jobs'" + cdataframe: "continuous data frame" + cdataframes: "continuous data frames" + cdataframe-cap: "Continuous data frame" + cdataframes-cap: "Continuous data frames" + cdataframe-transform: "continuous transform" + cdataframe-transforms: "continuous transforms" + cdataframe-transforms-cap: "Continuous transforms" + ctransform: "continuous transform" + ctransform-cap: "Continuous transform" + ctransforms: "continuous transforms" + ctransforms-cap: "Continuous transforms" + oldetection: "outlier detection" + oldetection-cap: "Outlier detection" + olscore: "outlier score" + olscores: "outlier scores" + fiscore: "feature influence score" + evaluatedf-api: "evaluate {dataframe} analytics API" + evaluatedf-api-cap: "Evaluate {dataframe} analytics API" + binarysc: "binary soft classification" + binarysc-cap: "Binary soft classification" + regression: "regression" + regression-cap: "Regression" + reganalysis: "regression analysis" + reganalysis-cap: "Regression analysis" + depvar: "dependent variable" + feature-var: "feature variable" + feature-vars: "feature variables" + feature-vars-cap: "Feature variables" + classification: "classification" + classification-cap: "Classification" + classanalysis: "classification analysis" + classanalysis-cap: "Classification analysis" + infer-cap: "Inference" + infer: "inference" + lang-ident-cap: "Language identification" + lang-ident: "language identification" + data-viz: "Data Visualizer" + file-data-viz: "File Data Visualizer" + feat-imp: "feature importance" + feat-imp-cap: "Feature importance" + nlp: "natural language processing" + nlp-cap: "Natural language processing" + apm-agent: "APM agent" + apm-go-agent: "Elastic APM Go agent" + apm-go-agents: "Elastic APM Go agents" + apm-ios-agent: "Elastic APM iOS agent" + apm-ios-agents: "Elastic APM iOS agents" + apm-java-agent: "Elastic APM Java agent" + apm-java-agents: "Elastic APM Java agents" + apm-dotnet-agent: "Elastic APM .NET agent" + apm-dotnet-agents: "Elastic APM .NET agents" + apm-node-agent: "Elastic APM Node.js agent" + apm-node-agents: "Elastic APM Node.js agents" + apm-php-agent: "Elastic APM PHP agent" + apm-php-agents: "Elastic APM PHP agents" + apm-py-agent: "Elastic APM Python agent" + apm-py-agents: "Elastic APM Python agents" + apm-ruby-agent: "Elastic APM Ruby agent" + apm-ruby-agents: "Elastic APM Ruby agents" + apm-rum-agent: "Elastic APM Real User Monitoring (RUM) JavaScript agent" + apm-rum-agents: "Elastic APM RUM JavaScript agents" + apm-lambda-ext: "Elastic APM AWS Lambda extension" + project-monitors: "project monitors" + project-monitors-cap: "Project monitors" + private-location: "Private Location" + private-locations: "Private Locations" + pwd: "YOUR_PASSWORD" + esh: "ES-Hadoop" + default-dist: "default distribution" + oss-dist: "OSS-only distribution" + observability: "Observability" + api-request-title: "Request" + api-prereq-title: "Prerequisites" + api-description-title: "Description" + api-path-parms-title: "Path parameters" + api-query-parms-title: "Query parameters" + api-request-body-title: "Request body" + api-response-codes-title: "Response codes" + api-response-body-title: "Response body" + api-example-title: "Example" + api-examples-title: "Examples" + api-definitions-title: "Properties" + multi-arg: "†footnoteref:[multi-arg,This parameter accepts multiple arguments.]" + multi-arg-ref: "†footnoteref:[multi-arg]" + yes-icon: "image:https://doc-icons.s3.us-east-2.amazonaws.com/icon-yes.png[Yes,20,15]" + no-icon: "image:https://doc-icons.s3.us-east-2.amazonaws.com/icon-no.png[No,20,15]" + es-repo: "https://github.com/elastic/elasticsearch/" + es-issue: "https://github.com/elastic/elasticsearch/issues/" + es-pull: "https://github.com/elastic/elasticsearch/pull/" + es-commit: "https://github.com/elastic/elasticsearch/commit/" + kib-repo: "https://github.com/elastic/kibana/" + kib-issue: "https://github.com/elastic/kibana/issues/" + kibana-issue: "'{kib-repo}issues/'" + kib-pull: "https://github.com/elastic/kibana/pull/" + kibana-pull: "'{kib-repo}pull/'" + kib-commit: "https://github.com/elastic/kibana/commit/" + ml-repo: "https://github.com/elastic/ml-cpp/" + ml-issue: "https://github.com/elastic/ml-cpp/issues/" + ml-pull: "https://github.com/elastic/ml-cpp/pull/" + ml-commit: "https://github.com/elastic/ml-cpp/commit/" + apm-repo: "https://github.com/elastic/apm-server/" + apm-issue: "https://github.com/elastic/apm-server/issues/" + apm-pull: "https://github.com/elastic/apm-server/pull/" + kibana-blob: "https://github.com/elastic/kibana/blob/current/" + apm-get-started-ref: "https://www.elastic.co/guide/en/apm/get-started/current" + apm-server-ref: "https://www.elastic.co/guide/en/apm/server/current" + apm-server-ref-v: "https://www.elastic.co/guide/en/apm/server/current" + apm-server-ref-m: "https://www.elastic.co/guide/en/apm/server/master" + apm-server-ref-62: "https://www.elastic.co/guide/en/apm/server/6.2" + apm-server-ref-64: "https://www.elastic.co/guide/en/apm/server/6.4" + apm-server-ref-70: "https://www.elastic.co/guide/en/apm/server/7.0" + apm-overview-ref-v: "https://www.elastic.co/guide/en/apm/get-started/current" + apm-overview-ref-70: "https://www.elastic.co/guide/en/apm/get-started/7.0" + apm-overview-ref-m: "https://www.elastic.co/guide/en/apm/get-started/master" + infra-guide: "https://www.elastic.co/guide/en/infrastructure/guide/current" + a-data-source: "a data view" + icon-bug: "pass:[]" + icon-checkInCircleFilled: "pass:[]" + icon-warningFilled: "pass:[]" diff --git a/docs/extend/codec-new-plugin.md b/docs/extend/codec-new-plugin.md new file mode 100644 index 000000000..00595c640 --- /dev/null +++ b/docs/extend/codec-new-plugin.md @@ -0,0 +1,636 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/codec-new-plugin.html +--- + +# How to write a Logstash codec plugin [codec-new-plugin] + +To develop a new codec for Logstash, build a self-contained Ruby gem whose source code lives in its own GitHub repository. The Ruby gem can then be hosted and shared on RubyGems.org. You can use the example codec implementation as a starting point. (If you’re unfamiliar with Ruby, you can find an excellent quickstart guide at [https://www.ruby-lang.org/en/documentation/quickstart/](https://www.ruby-lang.org/en/documentation/quickstart/).) + +## Get started [_get_started_2] + +Let’s step through creating a codec plugin using the [example codec plugin](https://github.com/logstash-plugins/logstash-codec-example/). + +### Create a GitHub repo for your new plugin [_create_a_github_repo_for_your_new_plugin_2] + +Each Logstash plugin lives in its own GitHub repository. To create a new repository for your plugin: + +1. Log in to GitHub. +2. Click the **Repositories** tab. You’ll see a list of other repositories you’ve forked or contributed to. +3. Click the green **New** button in the upper right. +4. Specify the following settings for your new repo: + + * **Repository name** — a unique name of the form `logstash-codec-pluginname`. + * **Public or Private** — your choice, but the repository must be Public if you want to submit it as an official plugin. + * **Initialize this repository with a README** — enables you to immediately clone the repository to your computer. + +5. Click **Create Repository**. + + +### Use the plugin generator tool [_use_the_plugin_generator_tool_2] + +You can create your own Logstash plugin in seconds! The `generate` subcommand of `bin/logstash-plugin` creates the foundation for a new Logstash plugin with templatized files. It creates the correct directory structure, gemspec files, and dependencies so you can start adding custom code to process data with Logstash. + +For more information, see [Generating plugins](/reference/plugin-generator.md) + + +### Copy the codec code [_copy_the_codec_code] + +Alternatively, you can use the examples repo we host on github.com + +1. **Clone your plugin.** Replace `GITUSERNAME` with your github username, and `MYPLUGINNAME` with your plugin name. + + * `git clone https://github.com/GITUSERNAME/logstash-``codec-MYPLUGINNAME.git` + + * alternately, via ssh: `git clone git@github.com:GITUSERNAME/logstash``-codec-MYPLUGINNAME.git` + + * `cd logstash-codec-MYPLUGINNAME` + +2. **Clone the codec plugin example and copy it to your plugin branch.** + + You don’t want to include the example .git directory or its contents, so delete it before you copy the example. + + * `cd /tmp` + * `git clone https://github.com/logstash-plugins/logstash``-codec-example.git` + * `cd logstash-codec-example` + * `rm -rf .git` + * `cp -R * /path/to/logstash-codec-mypluginname/` + +3. **Rename the following files to match the name of your plugin.** + + * `logstash-codec-example.gemspec` + * `example.rb` + * `example_spec.rb` + + ```txt + cd /path/to/logstash-codec-mypluginname + mv logstash-codec-example.gemspec logstash-codec-mypluginname.gemspec + mv lib/logstash/codecs/example.rb lib/logstash/codecs/mypluginname.rb + mv spec/codecs/example_spec.rb spec/codecs/mypluginname_spec.rb + ``` + + +Your file structure should look like this: + +```txt +$ tree logstash-codec-mypluginname +├── Gemfile +├── LICENSE +├── README.md +├── Rakefile +├── lib +│   └── logstash +│   └── codecs +│   └── mypluginname.rb +├── logstash-codec-mypluginname.gemspec +└── spec + └── codecs + └── mypluginname_spec.rb +``` + +For more information about the Ruby gem file structure and an excellent walkthrough of the Ruby gem creation process, see [http://timelessrepo.com/making-ruby-gems](http://timelessrepo.com/making-ruby-gems) + + +### See what your plugin looks like [_see_what_your_plugin_looks_like_2] + +Before we dive into the details, open up the plugin file in your favorite text editor and take a look. + +```ruby +require "logstash/codecs/base" +require "logstash/codecs/line" + +# Add any asciidoc formatted documentation here +class LogStash::Codecs::Example < LogStash::Codecs::Base + + # This example codec will append a string to the message field + # of an event, either in the decoding or encoding methods + # + # This is only intended to be used as an example. + # + # input { + # stdin { codec => example } + # } + # + # or + # + # output { + # stdout { codec => example } + # } + config_name "example" + + # Append a string to the message + config :append, :validate => :string, :default => ', Hello World!' + + public + def register + @lines = LogStash::Codecs::Line.new + @lines.charset = "UTF-8" + end + + public + def decode(data) + @lines.decode(data) do |line| + replace = { "message" => line["message"].to_s + @append } + yield LogStash::Event.new(replace) + end + end # def decode + + public + def encode(event) + @on_event.call(event, event.get("message").to_s + @append + NL) + end # def encode + +end # class LogStash::Codecs::Example +``` + + + +## Coding codec plugins [_coding_codec_plugins] + +Now let’s take a line-by-line look at the example plugin. + +### `require` Statements [_require_statements_2] + +Logstash codec plugins require parent classes defined in `logstash/codecs/base` and logstash/namespace: + +```ruby +require "logstash/codecs/base" +require "logstash/namespace" +``` + +Of course, the plugin you build may depend on other code, or even gems. Just put them here along with these Logstash dependencies. + + + +## Plugin Body [_plugin_body_2] + +Let’s go through the various elements of the plugin itself. + +### `class` Declaration [_class_declaration_2] + +The codec plugin class should be a subclass of `LogStash::Codecs::Base`: + +```ruby +class LogStash::Codecs::Example < LogStash::Codecs::Base +``` + +The class name should closely mirror the plugin name, for example: + +```ruby +LogStash::Codecs::Example +``` + + +### `config_name` [_config_name_2] + +```ruby + config_name "example" +``` + +This is the name your plugin will call inside the codec configuration block. + +If you set `config_name "example"` in your plugin code, the corresponding Logstash configuration block would need to look like this: + + + +## Configuration Parameters [_configuration_parameters_2] + +```ruby + config :variable_name, :validate => :variable_type, :default => "Default value", :required => boolean, :deprecated => boolean, :obsolete => string +``` + +The configuration, or `config` section allows you to define as many (or as few) parameters as are needed to enable Logstash to process events. + +There are several configuration attributes: + +* `:validate` - allows you to enforce passing a particular data type to Logstash for this configuration option, such as `:string`, `:password`, `:boolean`, `:number`, `:array`, `:hash`, `:path` (a file-system path), `uri`, `:codec` (since 1.2.0), `:bytes`. Note that this also works as a coercion in that if I specify "true" for boolean (even though technically a string), it will become a valid boolean in the config. This coercion works for the `:number` type as well where "1.2" becomes a float and "22" is an integer. +* `:default` - lets you specify a default value for a parameter +* `:required` - whether or not this parameter is mandatory (a Boolean `true` or +* `:list` - whether or not this value should be a list of values. Will typecheck the list members, and convert scalars to one element lists. Note that this mostly obviates the array type, though if you need lists of complex objects that will be more suitable. `false`) +* `:deprecated` - informational (also a Boolean `true` or `false`) +* `:obsolete` - used to declare that a given setting has been removed and is no longer functioning. The idea is to provide an informed upgrade path to users who are still using a now-removed setting. + + +## Plugin Methods [_plugin_methods_2] + +Logstash codecs must implement the `register` method, and the `decode` method or the `encode` method (or both). + +### `register` Method [_register_method_2] + +```ruby + public + def register + end # def register +``` + +The Logstash `register` method is like an `initialize` method. It was originally created to enforce having `super` called, preventing headaches for newbies. (Note: It may go away in favor of `initialize`, in conjunction with some enforced testing to ensure `super` is called.) + +`public` means the method can be called anywhere, not just within the class. This is the default behavior for methods in Ruby, but it is specified explicitly here anyway. + +You can also assign instance variables here (variables prepended by `@`). Configuration variables are now in scope as instance variables, like `@message` + + +### `decode` Method [_decode_method] + +```ruby + public + def decode(data) + @lines.decode(data) do |line| + replace = { "message" => line["message"].to_s + @append } + yield LogStash::Event.new(replace) + end + end # def decode +``` + +The codec’s `decode` method is where data coming in from an input is transformed into an event. There are complex examples like the [collectd](https://github.com/logstash-plugins/logstash-codec-collectd/blob/main/lib/logstash/codecs/collectd.rb#L386-L484) codec, and simpler examples like the [spool](https://github.com/logstash-plugins/logstash-codec-spool/blob/main/lib/logstash/codecs/spool.rb#L11-L16) codec. + +There must be a `yield` statement as part of the `decode` method which will return decoded events to the pipeline. + + +### `encode` Method [_encode_method] + +```ruby + public + def encode(event) + @on_event.call(event, event.get("message").to_s + @append + NL) + end # def encode +``` + +The `encode` method takes an event and serializes it (*encodes*) into another format. Good examples of `encode` methods include the simple [plain](https://github.com/logstash-plugins/logstash-codec-plain/blob/main/lib/logstash/codecs/plain.rb#L39-L46) codec, the slightly more involved [msgpack](https://github.com/logstash-plugins/logstash-codec-msgpack/blob/main/lib/logstash/codecs/msgpack.rb#L38-L46) codec, and even an [avro](https://github.com/logstash-plugins/logstash-codec-avro/blob/main/lib/logstash/codecs/avro.rb#L38-L45) codec. + +In most cases, your `encode` method should have an `@on_event.call()` statement. This call will output data per event in the described way. + + + +## Building the Plugin [_building_the_plugin_2] + +At this point in the process you have coded your plugin and are ready to build a Ruby Gem from it. The following information will help you complete the process. + +### External dependencies [_external_dependencies_2] + +A `require` statement in Ruby is used to include necessary code. In some cases your plugin may require additional files. For example, the collectd plugin [uses](https://github.com/logstash-plugins/logstash-codec-collectd/blob/main/lib/logstash/codecs/collectd.rb#L148) the `types.db` file provided by collectd. In the main directory of your plugin, a file called `vendor.json` is where these files are described. + +The `vendor.json` file contains an array of JSON objects, each describing a file dependency. This example comes from the [collectd](https://github.com/logstash-plugins/logstash-codec-collectd/blob/main/vendor.json) codec plugin: + +```txt +[{ + "sha1": "a90fe6cc53b76b7bdd56dc57950d90787cb9c96e", + "url": "http://collectd.org/files/collectd-5.4.0.tar.gz", + "files": [ "/src/types.db" ] +}] +``` + +* `sha1` is the sha1 signature used to verify the integrity of the file referenced by `url`. +* `url` is the address from where Logstash will download the file. +* `files` is an optional array of files to extract from the downloaded file. Note that while tar archives can use absolute or relative paths, treat them as absolute in this array. If `files` is not present, all files will be uncompressed and extracted into the vendor directory. + +Another example of the `vendor.json` file is the [`geoip` filter](https://github.com/logstash-plugins/logstash-filter-geoip/blob/main/vendor.json) + +The process used to download these dependencies is to call `rake vendor`. This will be discussed further in the testing section of this document. + +Another kind of external dependency is on jar files. This will be described in the "Add a `gemspec` file" section. + + +### Deprecated features [_deprecated_features_2] + +As a plugin evolves, an option or feature may no longer serve the intended purpose, and the developer may want to *deprecate* its usage. Deprecation warns users about the option’s status, so they aren’t caught by surprise when it is removed in a later release. + +{{ls}} 7.6 introduced a *deprecation logger* to make handling those situations easier. You can use the [adapter](https://github.com/logstash-plugins/logstash-mixin-deprecation_logger_support) to ensure that your plugin can use the deprecation logger while still supporting older versions of {{ls}}. See the [readme](https://github.com/logstash-plugins/logstash-mixin-deprecation_logger_support/blob/main/README.md) for more information and for instructions on using the adapter. + +Deprecations are noted in the `logstash-deprecation.log` file in the `log` directory. + + +### Add a Gemfile [_add_a_gemfile_2] + +Gemfiles allow Ruby’s Bundler to maintain the dependencies for your plugin. Currently, all we’ll need is the Logstash gem, for testing, but if you require other gems, you should add them in here. + +::::{tip} +See [Bundler’s Gemfile page](http://bundler.io/gemfile.html) for more details. +:::: + + +```ruby +source 'https://rubygems.org' +gemspec +gem "logstash", :github => "elastic/logstash", :branch => "master" +``` + + + +## Add a `gemspec` file [_add_a_gemspec_file_2] + +Gemspecs define the Ruby gem which will be built and contain your plugin. + +::::{tip} +More information can be found on the [Rubygems Specification page](http://guides.rubygems.org/specification-reference/). +:::: + + +```ruby +Gem::Specification.new do |s| + s.name = 'logstash-codec-example' + s.version = '0.1.0' + s.licenses = ['Apache License (2.0)'] + s.summary = "This codec does x, y, z in Logstash" + s.description = "This gem is a logstash plugin required to be installed on top of the Logstash core pipeline using $LS_HOME/bin/logstash-plugin install gemname. This gem is not a stand-alone program" + s.authors = ["Elastic"] + s.email = 'info@elastic.co' + s.homepage = "http://www.elastic.co/guide/en/logstash/current/index.html" + s.require_paths = ["lib"] + + # Files + s.files = Dir['lib/**/*','spec/**/*','vendor/**/*','*.gemspec','*.md','CONTRIBUTORS','Gemfile','LICENSE','NOTICE.TXT'] + # Tests + s.test_files = s.files.grep(%r{^(test|spec|features)/}) + + # Special flag to let us know this is actually a logstash plugin + s.metadata = { "logstash_plugin" => "true", "logstash_group" => "codec" } + + # Gem dependencies + s.add_runtime_dependency "logstash-core-plugin-api", ">= 1.60", "<= 2.99" + s.add_development_dependency 'logstash-devutils' +end +``` + +It is appropriate to change these values to fit your plugin. In particular, `s.name` and `s.summary` should reflect your plugin’s name and behavior. + +`s.licenses` and `s.version` are also important and will come into play when you are ready to publish your plugin. + +Logstash and all its plugins are licensed under [Apache License, version 2 ("ALv2")](https://github.com/elastic/logstash/blob/main/LICENSE.txt). If you make your plugin publicly available via [RubyGems.org](http://rubygems.org), please make sure to have this line in your gemspec: + +* `s.licenses = ['Apache License (2.0)']` + +The gem version, designated by `s.version`, helps track changes to plugins over time. You should use [semver versioning](http://semver.org/) strategy for version numbers. + +### Runtime and Development Dependencies [_runtime_and_development_dependencies_2] + +At the bottom of the `gemspec` file is a section with a comment: `Gem dependencies`. This is where any other needed gems must be mentioned. If a gem is necessary for your plugin to function, it is a runtime dependency. If a gem are only used for testing, then it would be a development dependency. + +::::{note} +You can also have versioning requirements for your dependencies—​including other Logstash plugins: + +```ruby + # Gem dependencies + s.add_runtime_dependency "logstash-core-plugin-api", ">= 1.60", "<= 2.99" + s.add_development_dependency 'logstash-devutils' +``` + +This gemspec has a runtime dependency on the logstash-core-plugin-api and requires that it have a version number greater than or equal to version 1.60 and less than or equal to version 2.99. + +:::: + + +::::{important} +All plugins have a runtime dependency on the `logstash-core-plugin-api` gem, and a development dependency on `logstash-devutils`. +:::: + + + +### Jar dependencies [_jar_dependencies_2] + +In some cases, such as the [Elasticsearch output plugin](https://github.com/logstash-plugins/logstash-output-elasticsearch/blob/main/logstash-output-elasticsearch.gemspec#L22-L23), your code may depend on a jar file. In cases such as this, the dependency is added in the gemspec file in this manner: + +```ruby + # Jar dependencies + s.requirements << "jar 'org.elasticsearch:elasticsearch', '5.0.0'" + s.add_runtime_dependency 'jar-dependencies' +``` + +With these both defined, the install process will search for the required jar file at [http://mvnrepository.com](http://mvnrepository.com) and download the specified version. + + + +## Document your plugin [_document_your_plugin_2] + +Documentation is an important part of your plugin. All plugin documentation is rendered and placed in the [Logstash Reference](/reference/index.md) and the [Versioned plugin docs](logstash-docs://reference/integration-plugins.md). + +See [Document your plugin](/extend/plugin-doc.md) for tips and guidelines. + + +## Add Tests [_add_tests_2] + +Logstash loves tests. Lots of tests. If you’re using your new codec plugin in a production environment, you’ll want to have some tests to ensure you are not breaking any existing functionality. + +::::{note} +A full exposition on RSpec is outside the scope of this document. Learn more about RSpec at [http://rspec.info](http://rspec.info) +:::: + + +For help learning about tests and testing, look in the `spec/codecs/` directory of several other similar plugins. + + +## Clone and test! [_clone_and_test_2] + +Now let’s start with a fresh clone of the plugin, build it and run the tests. + +* **Clone your plugin into a temporary location** Replace `GITUSERNAME` with your github username, and `MYPLUGINNAME` with your plugin name. + + * `git clone https://github.com/GITUSERNAME/logstash-``codec-MYPLUGINNAME.git` + + * alternately, via ssh: `git clone git@github.com:GITUSERNAME/logstash-``codec-MYPLUGINNAME.git` + + * `cd logstash-codec-MYPLUGINNAME` + + +Then, you’ll need to install your plugins dependencies with bundler: + +``` +bundle install +``` + +::::{important} +If your plugin has an external file dependency described in `vendor.json`, you must download that dependency before running or testing. You can do this by running: + +``` +rake vendor +``` + +:::: + + +And finally, run the tests: + +``` +bundle exec rspec +``` + +You should see a success message, which looks something like this: + +``` +Finished in 0.034 seconds +1 example, 0 failures +``` + +Hooray! You’re almost there! (Unless you saw failures…​ you should fix those first). + + +## Building and Testing [_building_and_testing_2] + +Now you’re ready to build your (well-tested) plugin into a Ruby gem. + +### Build [_build_2] + +You already have all the necessary ingredients, so let’s go ahead and run the build command: + +```sh +gem build logstash-codec-example.gemspec +``` + +That’s it! Your gem should be built and be in the same path with the name + +```sh +logstash-codec-mypluginname-0.1.0.gem +``` + +The `s.version` number from your gemspec file will provide the gem version, in this case, `0.1.0`. + + +### Test installation [_test_installation_2] + +You should test install your plugin into a clean installation of Logstash. Download the latest version from the [Logstash downloads page](https://www.elastic.co/downloads/logstash/). + +1. Untar and cd in to the directory: + + ```sh + curl -O https://download.elastic.co/logstash/logstash/logstash-9.0.0.tar.gz + tar xzvf logstash-9.0.0.tar.gz + cd logstash-9.0.0 + ``` + +2. Using the plugin tool, we can install the gem we just built. + + * Replace `/my/logstash/plugins` with the correct path to the gem for your environment, and `0.1.0` with the correct version number from the gemspec file. + + ```sh + bin/logstash-plugin install /my/logstash/plugins/logstash-codec-example/logstash-codec-example-0.1.0.gem + ``` + + * After running this, you should see feedback from Logstash that it was successfully installed: + + ```sh + validating /my/logstash/plugins/logstash-codec-example/logstash-codec-example-0.1.0.gem >= 0 + Valid logstash plugin. Continuing... + Successfully installed 'logstash-codec-example' with version '0.1.0' + ``` + + ::::{tip} + You can also use the Logstash plugin tool to determine which plugins are currently available: + + ```sh + bin/logstash-plugin list + ``` + + Depending on what you have installed, you might see a short or long list of plugins: inputs, codecs, filters and outputs. + + :::: + +3. Now try running Logstash with a simple configuration passed in via the command-line, using the `-e` flag. + + ::::{note} + Your results will depend on what your codec plugin is designed to do. + :::: + + +```sh +bin/logstash -e 'input { stdin{ codec => example{}} } output {stdout { codec => rubydebug }}' +``` + +The example codec plugin will append the contents of `append` (which by default appends ", Hello World!") + +After starting Logstash, type something, for example "Random output string". The resulting output message field contents should be, "Random output string, Hello World!": + +```sh +Random output string +{ + "message" => "Random output string, Hello World!", + "@version" => "1", + "@timestamp" => "2015-01-27T19:17:18.932Z", + "host" => "cadenza" +} +``` + +Feel free to experiment and test this by changing the `append` parameter: + +```sh +bin/logstash -e 'input { stdin{ codec => example{ append => ", I am appending this! }} } output {stdout { codec => rubydebug }}' +``` + +Congratulations! You’ve built, deployed and successfully run a Logstash codec. + + + +## Submitting your plugin to [RubyGems.org](http://rubygems.org) and [logstash-plugins](https://github.com/logstash-plugins) [_submitting_your_plugin_to_rubygems_orghttprubygems_org_and_logstash_pluginshttpsgithub_comlogstash_plugins_2] + +Logstash uses [RubyGems.org](http://rubygems.org) as its repository for all plugin artifacts. Once you have developed your new plugin, you can make it available to Logstash users by simply publishing it to RubyGems.org. + +### Licensing [_licensing_2] + +Logstash and all its plugins are licensed under [Apache License, version 2 ("ALv2")](https://github.com/elasticsearch/logstash/blob/main/LICENSE). If you make your plugin publicly available via [RubyGems.org](http://rubygems.org), please make sure to have this line in your gemspec: + +* `s.licenses = ['Apache License (2.0)']` + + +### Publishing to [RubyGems.org](http://rubygems.org) [_publishing_to_rubygems_orghttprubygems_org_2] + +To begin, you’ll need an account on RubyGems.org + +* [Sign-up for a RubyGems account](https://rubygems.org/sign_up). + +After creating an account, [obtain](http://guides.rubygems.org/rubygems-org-api/#api-authorization) an API key from RubyGems.org. By default, RubyGems uses the file `~/.gem/credentials` to store your API key. These credentials will be used to publish the gem. Replace `username` and `password` with the credentials you created at RubyGems.org: + +```sh +curl -u username:password https://rubygems.org/api/v1/api_key.yaml > ~/.gem/credentials +chmod 0600 ~/.gem/credentials +``` + +Before proceeding, make sure you have the right version in your gemspec file and commit your changes. + +* `s.version = '0.1.0'` + +To publish version 0.1.0 of your new logstash gem: + +```sh +bundle install +bundle exec rake vendor +bundle exec rspec +bundle exec rake publish_gem +``` + +::::{note} +Executing `rake publish_gem`: + +1. Reads the version from the gemspec file (`s.version = '0.1.0'`) +2. Checks in your local repository if a tag exists for that version. If the tag already exists, it aborts the process. Otherwise, it creates a new version tag in your local repository. +3. Builds the gem +4. Publishes the gem to RubyGems.org + +:::: + + +That’s it! Your plugin is published! Logstash users can now install your plugin by running: + +```sh +bin/logstash-plugin install logstash-codec-mypluginname +``` + + + +## Contributing your source code to [logstash-plugins](https://github.com/logstash-plugins) [_contributing_your_source_code_to_logstash_pluginshttpsgithub_comlogstash_plugins_2] + +It is not required to contribute your source code to [logstash-plugins](https://github.com/logstash-plugins) github organization, but we always welcome new plugins! + +### Benefits [_benefits_2] + +Some of the many benefits of having your plugin in the logstash-plugins repository are: + +* **Discovery.** Your plugin will appear in the [Logstash Reference](/reference/index.md), where Logstash users look first for plugins and documentation. +* **Documentation.** Your plugin documentation will automatically be added to the [Logstash Reference](/reference/index.md). +* **Testing.** With our testing infrastructure, your plugin will be continuously tested against current and future releases of Logstash. As a result, users will have the assurance that if incompatibilities arise, they will be quickly discovered and corrected. + + +### Acceptance Guidelines [_acceptance_guidelines_2] + +* **Code Review.** Your plugin must be reviewed by members of the community for coherence, quality, readability, stability and security. +* **Tests.** Your plugin must contain tests to be accepted. These tests are also subject to code review for scope and completeness. It’s ok if you don’t know how to write tests — we will guide you. We are working on publishing a guide to creating tests for Logstash which will make it easier. In the meantime, you can refer to [http://betterspecs.org/](http://betterspecs.org/) for examples. + +To begin migrating your plugin to logstash-plugins, simply create a new [issue](https://github.com/elasticsearch/logstash/issues) in the Logstash repository. When the acceptance guidelines are completed, we will facilitate the move to the logstash-plugins organization using the recommended [github process](https://help.github.com/articles/transferring-a-repository/#transferring-from-a-user-to-an-organization). diff --git a/docs/extend/community-maintainer.md b/docs/extend/community-maintainer.md new file mode 100644 index 000000000..686d0012c --- /dev/null +++ b/docs/extend/community-maintainer.md @@ -0,0 +1,193 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/community-maintainer.html +--- + +# Logstash Plugins Community Maintainer Guide [community-maintainer] + +This document, to be read by new Maintainers, should explain their responsibilities. It was inspired by the [C4](http://rfc.zeromq.org/spec:22) document from the ZeroMQ project. This document is subject to change and suggestions through Pull Requests and issues are strongly encouraged. + + +## Contribution Guidelines [_contribution_guidelines] + +For general guidance around contributing to Logstash Plugins, see the [*Contributing to Logstash*](/extend/index.md) section. + + +## Document Goals [_document_goals] + +To help make the Logstash plugins community participation easy with positive feedback. + +To increase diversity. + +To reduce code review, merge and release dependencies on the core team by providing support and tools to the Community and Maintainers. + +To support the natural life cycle of a plugin. + +To codify the roles and responsibilities of: Maintainers and Contributors with specific focus on patch testing, code review, merging and release. + + +## Development Workflow [_development_workflow] + +All Issues and Pull Requests must be tracked using the Github issue tracker. + +The plugin uses the [Apache 2.0 license](http://www.apache.org/licenses/LICENSE-2.0). Maintainers should check whether a patch introduces code which has an incompatible license. Patch ownership and copyright is defined in the Elastic [Contributor License Agreement](https://www.elastic.co/contributor-agreement) (CLA). + + +### Terminology [_terminology_2] + +A "Contributor" is a role a person assumes when providing a patch. Contributors will not have commit access to the repository. They need to sign the Elastic [Contributor License Agreement](https://www.elastic.co/contributor-agreement) before a patch can be reviewed. Contributors can add themselves to the plugin Contributor list. + +A "Maintainer" is a role a person assumes when maintaining a plugin and keeping it healthy, including triaging issues, and reviewing and merging patches. + + +### Patch Requirements [_patch_requirements] + +A patch is a minimal and accurate answer to exactly one identified and agreed upon problem. It must conform to the [code style guidelines](https://github.com/elastic/logstash/blob/main/STYLE.md) and must include RSpec tests that verify the fitness of the solution. + +A patch will be automatically tested by a CI system that will report on the Pull Request status. + +A patch CLA will be automatically verified and reported on the Pull Request status. + +A patch commit message has a single short (less than 50 character) first line summarizing the change, a blank second line, and any additional lines as necessary for change explanation and rationale. + +A patch is mergeable when it satisfies the above requirements and has been reviewed positively by at least one other person. + + +### Development Process [_development_process] + +A user will log an issue on the issue tracker describing the problem they face or observe with as much detail as possible. + +To work on an issue, a Contributor forks the plugin repository and then works on their forked repository and submits a patch by creating a pull request back to the plugin. + +Maintainers must not merge patches where the author has not signed the CLA. + +Before a patch can be accepted it should be reviewed. Maintainers should merge accepted patches without delay. + +Maintainers should not merge their own patches except in exceptional cases, such as non-responsiveness from other Maintainers or core team for an extended period (more than 2 weeks). + +Reviewer’s comments should not be based on personal preferences. + +The Maintainers should label Issues and Pull Requests. + +Maintainers should involve the core team if help is needed to reach consensus. + +Review non-source changes such as documentation in the same way as source code changes. + + +### Branch Management [_branch_management] + +The plugin has a main branch that always holds the latest in-progress version and should always build. Topic branches should kept to the minimum. + + +### Changelog Management [_changelog_management] + +Every plugin should have a changelog (https://www.elastic.co/guide/en/logstash/current/CHANGELOG.html). If not, please create one. When changes are made to a plugin, make sure to include a changelog entry under the respective version to document the change. The changelog should be easily understood from a user point of view. As we iterate and release plugins rapidly, users use the changelog as a mechanism for deciding whether to update. + +Changes that are not user facing should be tagged as `internal:`. For example: + +```markdown + - internal: Refactored specs for better testing + - config: Default timeout configuration changed from 10s to 5s +``` + + +#### Detailed format of https://www.elastic.co/guide/en/logstash/current/CHANGELOG.html [_detailed_format_of_changelog_md] + +Sharing a similar format of https://www.elastic.co/guide/en/logstash/current/CHANGELOG.html in plugins ease readability for users. Please see following annotated example and see a concrete example in [logstash-filter-date](https://raw.githubusercontent.com/logstash-plugins/logstash-filter-date/main/https://www.elastic.co/guide/en/logstash/current/CHANGELOG.html). + +```markdown +## 1.0.x <1> + - change description <2> + - tag: change description <3> + - tag1,tag2: change description <4> + - tag: Multi-line description <5> + must be indented and can use + additional markdown syntax + <6> +## 1.0.0 <7> +[...] +``` + +1. Latest version is the first line of https://www.elastic.co/guide/en/logstash/current/CHANGELOG.html. Each version identifier should be a level-2 header using `##` +2. One change description is described as a list item using a dash `-` aligned under the version identifier +3. One change can be tagged by a word and suffixed by `:`.
Common tags are `bugfix`, `feature`, `doc`, `test` or `internal`. +4. One change can have multiple tags separated by a comma and suffixed by `:` +5. A multi-line change description must be properly indented +6. Please take care to **separate versions with an empty line** +7. Previous version identifier + + + +### Continuous Integration [_continuous_integration] + +Plugins are setup with automated continuous integration (CI) environments and there should be a corresponding badge on each Github page. If it’s missing, please contact the Logstash core team. + +Every Pull Request opened automatically triggers a CI run. To conduct a manual run, comment “Jenkins, please test this.” on the Pull Request. + + +## Versioning Plugins [_versioning_plugins] + +Logstash core and its plugins have separate product development lifecycles. Hence the versioning and release strategy for the core and plugins do not have to be aligned. In fact, this was one of our goals during the great separation of plugins work in Logstash 1.5. + +At times, there will be changes in core API in Logstash, which will require mass update of plugins to reflect the changes in core. However, this does not happen frequently. + +For plugins, we would like to adhere to a versioning and release strategy that can better inform our users, about any breaking changes to the Logstash configuration formats and functionality. + +Plugin releases follows a three-placed numbering scheme X.Y.Z. where X denotes a major release version which may break compatibility with existing configuration or functionality. Y denotes releases which includes features which are backward compatible. Z denotes releases which includes bug fixes and patches. + + +### Changing the version [_changing_the_version] + +Version can be changed in the Gemspec, which needs to be associated with a changelog entry. Following this, we can publish the gem to RubyGem.org manually. At this point only the core developers can publish a gem. + + +### Labeling [_labeling] + +Labeling is a critical aspect of maintaining plugins. All issues in GitHub should be labeled correctly so it can: + +* Provide good feedback to users/developers +* Help prioritize changes +* Be used in release notes + +Most labels are self explanatory, but here’s a quick recap of few important labels: + +* `bug`: Labels an issue as an unintentional defect +* `needs details`: If a the issue reporter has incomplete details, please ask them for more info and label as needs details. +* `missing cla`: Contributor License Agreement is missing and patch cannot be accepted without it +* `adopt me`: Ask for help from the community to take over this issue +* `enhancement`: New feature, not a bug fix +* `needs tests`: Patch has no tests, and cannot be accepted without unit/integration tests +* `docs`: Documentation related issue/PR + + +## Logging [_logging] + +Although it’s important not to bog down performance with excessive logging, debug level logs can be immensely helpful when diagnosing and troubleshooting issues with Logstash. Please remember to liberally add debug logs wherever it makes sense as users will be forever gracious. + +```shell +@logger.debug("Logstash loves debug logs!", :actions => actions) +``` + + +## Contributor License Agreement (CLA) Guidance [_contributor_license_agreement_cla_guidance] + +Why is a [CLA](https://www.elastic.co/contributor-agreement) required? +: We ask this of all Contributors in order to assure our users of the origin and continuing existence of the code. We are not asking Contributors to assign copyright to us, but to give us the right to distribute a Contributor’s code without restriction. + +Please make sure the CLA is signed by every Contributor prior to reviewing PRs and commits. +: Contributors only need to sign the CLA once and should sign with the same email as used in Github. If a Contributor signs the CLA after a PR is submitted, they can refresh the automated CLA checker by pushing another comment on the PR after 5 minutes of signing. + + +## Need Help? [_need_help] + +Ping @logstash-core on Github to get the attention of the Logstash core team. + + +## Community Administration [_community_administration] + +The core team is there to support the plugin Maintainers and overall ecosystem. + +Maintainers should propose Contributors to become a Maintainer. + +Contributors and Maintainers should follow the Elastic Community [Code of Conduct](https://www.elastic.co/community/codeofconduct). The core team should block or ban "bad actors". + diff --git a/docs/extend/contribute-to-core.md b/docs/extend/contribute-to-core.md new file mode 100644 index 000000000..fbc7043ca --- /dev/null +++ b/docs/extend/contribute-to-core.md @@ -0,0 +1,11 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/contribute-to-core.html +--- + +# Extending Logstash core [contribute-to-core] + +We also welcome contributions and bug fixes to the Logstash core feature set. + +Please read through our [contribution](https://github.com/elastic/logstash/blob/main/CONTRIBUTING.md) guide, and the Logstash [readme](https://github.com/elastic/logstash/blob/main/README.md) document. + diff --git a/docs/extend/contributing-patch-plugin.md b/docs/extend/contributing-patch-plugin.md new file mode 100644 index 000000000..a1621fd56 --- /dev/null +++ b/docs/extend/contributing-patch-plugin.md @@ -0,0 +1,386 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/contributing-patch-plugin.html +--- + +# Contributing a patch to a Logstash plugin [contributing-patch-plugin] + +This section discusses the information you need to know to successfully contribute a patch to a Logstash plugin. + +Each plugin defines its own configuration options. These control the behavior of the plugin to some degree. Configuration option definitions commonly include: + +* Data validation +* Default value +* Any required flags + +Plugins are subclasses of a Logstash base class. A plugin’s base class defines common configuration and methods. + +## Input plugins [contrib-patch-input] + +Input plugins ingest data from an external source. Input plugins are always associated with a codec. An input plugin always has an associated codec plugin. Input and codec plugins operate in conjunction to create a Logstash event and add that event to the processing queue. An input codec is a subclass of the `LogStash::Inputs::Base` class. + +### Input API [input-api] + +`#register() -> nil` +: Required. This API sets up resources for the plugin, typically the connection to the external source. + +`#run(queue) -> nil` +: Required. This API fetches or listens for source data, typically looping until stopped. Must handle errors inside the loop. Pushes any created events to the queue object specified in the method argument. Some inputs may receive batched data to minimize the external call overhead. + +`#stop() -> nil` +: Optional. Stops external connections and cleans up. + + + +## Codec plugins [contrib-patch-codec] + +Codec plugins decode input data that has a specific structure, such as JSON input data. A codec plugin is a subclass of `LogStash::Codecs::Base`. + +### Codec API [codec-api] + +`#register() -> nil` +: Identical to the API of the same name for input plugins. + +`#decode(data){|event| block} -> nil` +: Must be implemented. Used to create an Event from the raw data given in the method argument. Must handle errors. The caller must provide a Ruby block. The block is called with the created Event. + +`#encode(event) -> nil` +: Required. Used to create a structured data object from the given Event. May handle errors. This method calls a block that was previously stored as @on_event with two arguments: the original event and the data object. + + + +## Filter plugins [contrib-patch-filter] + +A mechanism to change, mutate or merge one or more Events. A filter plugin is a subclass of the `LogStash::Filters::Base` class. + +### Filter API [filter-api] + +`#register() -> nil` +: Identical to the API of the same name for input plugins. + +`#filter(event) -> nil` +: Required. May handle errors. Used to apply a mutation function to the given event. + + + +## Output plugins [contrib-patch-output] + +A mechanism to send an event to an external destination. This process may require serialization. An output plugin is a subclass of the `LogStash::Outputs::Base` class. + +### Output API [output-api] + +`#register() -> nil` +: Identical to the API of the same name for input plugins. + +`#receive(event) -> nil` +: Required. Must handle errors. Used to prepare the given event for transmission to the external destination. Some outputs may buffer the prepared events to batch transmit to the destination. + + + +## Process [patch-process] + +A bug or feature is identified. An issue is created in the plugin repository. A patch is created and a pull request (PR) is submitted. After review and possible rework the PR is merged and the plugin is published. + +The [Community Maintainer Guide](/extend/community-maintainer.md) explains, in more detail, the process of getting a patch accepted, merged and published. The Community Maintainer Guide also details the roles that contributors and maintainers are expected to perform. + + +## Testing methodologies [test-methods] + +### Test driven development [tdd] + +Test driven development (TDD) describes a methodology for using tests to guide evolution of source code. For our purposes, we are use only a part of it. Before writing the fix, we create tests that illustrate the bug by failing. We stop when we have written enough code to make the tests pass and submit the fix and tests as a patch. It is not necessary to write the tests before the fix, but it is very easy to write a passing test afterwards that may not actually verify that the fault is really fixed especially if the fault can be triggered via multiple execution paths or varying input data. + + +### RSpec framework [rspec] + +Logstash uses Rspec, a Ruby testing framework, to define and run the test suite. What follows is a summary of various sources. + +```ruby + 2 require "logstash/devutils/rspec/spec_helper" + 3 require "logstash/plugin" + 4 + 5 describe "outputs/riemann" do + 6 describe "#register" do + 7 let(:output) do + 8 LogStash::Plugin.lookup("output", "riemann").new(configuration) + 9 end +10 +11 context "when no protocol is specified" do +12 let(:configuration) { Hash.new } +13 +14 it "the method completes without error" do +15 expect {output.register}.not_to raise_error +16 end +17 end +18 +19 context "when a bad protocol is specified" do +20 let(:configuration) { {"protocol" => "fake"} } +21 +22 it "the method fails with error" do +23 expect {output.register}.to raise_error +24 end +25 end +26 +27 context "when the tcp protocol is specified" do +28 let(:configuration) { {"protocol" => "tcp"} } +29 +30 it "the method completes without error" do +31 expect {output.register}.not_to raise_error +32 end +33 end +34 end +35 +36 describe "#receive" do +37 let(:output) do +38 LogStash::Plugin.lookup("output", "riemann").new(configuration) +39 end +40 +41 context "when operating normally" do +42 let(:configuration) { Hash.new } +43 let(:event) do +44 data = {"message"=>"hello", "@version"=>"1", +45 "@timestamp"=>"2015-06-03T23:34:54.076Z", +46 "host"=>"vagrant-ubuntu-trusty-64"} +47 LogStash::Event.new(data) +48 end +49 +50 before(:example) do +51 output.register +52 end +53 +54 it "should accept the event" do +55 expect { output.receive event }.not_to raise_error +56 end +57 end +58 end +59 end +``` + +```ruby +describe(string){block} -> nil +describe(Class){block} -> nil +``` + +With RSpec, we are always describing the plugin method behavior. The describe block is added in logical sections and can accept either an existing class name or a string. The string used in line 5 is the plugin name. Line 6 is the register method, line 36 is the receive method. It is a RSpec convention to prefix instance methods with one hash and class methods with one dot. + +```ruby +context(string){block} -> nil +``` + +In RSpec, context blocks define sections that group tests by a variation. The string should start with the word `when` and then detail the variation. See line 11. The tests in the content block should should only be for that variation. + +```ruby +let(symbol){block} -> nil +``` + +In RSpec, `let` blocks define resources for use in the test blocks. These resources are reinitialized for every test block. They are available as method calls inside the test block. Define `let` blocks in `describe` and `context` blocks, which scope the `let` block and any other nested blocks. You can use other `let` methods defined later within the `let` block body. See lines 7-9, which define the output resource and use the configuration method, defined with different variations in lines 12, 20 and 28. + +```ruby +before(symbol){block} -> nil - symbol is one of :suite, :context, :example, but :all and :each are synonyms for :suite and :example respectively. +``` + +In RSpec, `before` blocks are used to further set up any resources that would have been initialized in a `let` block. You cannot define `let` blocks inside `before` blocks. + +You can also define `after` blocks, which are typically used to clean up any setup activity performed by a `before` block. + +```ruby +it(string){block} -> nil +``` + +In RSpec, `it` blocks set the expectations that verify the behavior of the tested code. The string should not start with *it* or *should*, but needs to express the outcome of the expectation. When put together the texts from the enclosing describe, `context` and `it` blocks should form a fairly readable sentence, as in lines 5, 6, 11 and 14: + +```ruby +outputs/riemann +#register when no protocol is specified the method completes without error +``` + +Readable code like this make the goals of tests easy to understand. + +```ruby +expect(object){block} -> nil +``` + +In RSpec, the expect method verifies a statement that compares an actual result to an expected result. The `expect` method is usually paired with a call to the `to` or `not_to` methods. Use the block form when expecting errors or observing for changes. The `to` or `not_to` methods require a `matcher` object that encapsulates the expected value. The argument form of the `expect` method encapsulates the actual value. When put together the whole line tests the actual against the expected value. + +```ruby +raise_error(error class|nil) -> matcher instance +be(object) -> matcher instance +eq(object) -> matcher instance +eql(object) -> matcher instance + for more see http://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers +``` + +In RSpec, a matcher is an object generated by the equivalent method call (be, eq) that will be used to evaluate the expected against the actual values. + + + +## Putting it all together [all-together] + +This example fixes an [issue](https://github.com/logstash-plugins/logstash-output-zeromq/issues/9) in the ZeroMQ output plugin. The issue does not require knowledge of ZeroMQ. + +The activities in this example have the following prerequisites: + +* A minimal knowledge of Git and Github. See the [Github boot camp](https://help.github.com/categories/bootcamp/). +* A text editor. +* A JRuby [runtime](https://www.ruby-lang.org/en/documentation/installation/#managers) [environment](https://howistart.org/posts/ruby/1). The `chruby` tool manages Ruby versions. +* JRuby 1.7.22 or later. +* The `bundler` and `rake` gems installed. +* ZeroMQ [installed](http://zeromq.org/intro:get-the-software). + +1. In Github, fork the ZeroMQ [output plugin repository](https://github.com/logstash-plugins/logstash-output-zeromq). +2. On your local machine, [clone](https://help.github.com/articles/fork-a-repo/) the fork to a known folder such as `logstash/`. +3. Open the following files in a text editor: + + * `logstash-output-zeromq/lib/logstash/outputs/zeromq.rb` + * `logstash-output-zeromq/lib/logstash/util/zeromq.rb` + * `logstash-output-zeromq/spec/outputs/zeromq_spec.rb` + +4. According to the issue, log output in server mode must indicate `bound`. Furthermore, the test file contains no tests. + + ::::{note} + Line 21 of `util/zeromq.rb` reads `@logger.info("0mq: #{server? ? 'connected' : 'bound'}", :address => address)` + :::: + +5. In the text editor, require `zeromq.rb` for the file `zeromq_spec.rb` by adding the following lines: + + ```ruby + require "logstash/outputs/zeromq" + require "logstash/devutils/rspec/spec_helper" + ``` + +6. The desired error message should read: + + ```ruby + LogStash::Outputs::ZeroMQ when in server mode a 'bound' info line is logged + ``` + + To properly generate this message, add a `describe` block with the fully qualified class name as the argument, a context block, and an `it` block. + + ```ruby + describe LogStash::Outputs::ZeroMQ do + context "when in server mode" do + it "a 'bound' info line is logged" do + end + end + end + ``` + +7. To add the missing test, use an instance of the ZeroMQ output and a substitute logger. This example uses an RSpec feature called *test doubles* as the substitute logger. + + Add the following lines to `zeromq_spec.rb`, after `describe LogStash::Outputs::ZeroMQ do` and before `context "when in server mode" do`: + + ```ruby + let(:output) { described_class.new("mode" => "server", "topology" => "pushpull" } + let(:tracer) { double("logger") } + ``` + +8. Add the body to the `it` block. Add the following five lines after the line `context "when in server mode" do`: + + ```ruby + allow(tracer).to receive(:debug)<1> + output.logger = logger<2> + expect(tracer).to receive(:info).with("0mq: bound", {:address=>"tcp://127.0.0.1:2120"})<3> + output.register<4> + output.do_close<5> + ``` + + +1. Allow the double to receive `debug` method calls. +2. Make the output use the test double. +3. Set an expectation on the test to receive an `info` method call. +4. Call `register` on the output. +5. Call `do_close` on the output so the test does not hang. + + +At the end of the modifications, the relevant code section reads: + +```ruby +require "logstash/outputs/zeromq" +require "logstash/devutils/rspec/spec_helper" + +describe LogStash::Outputs::ZeroMQ do + let(:output) { described_class.new("mode" => "server", "topology" => "pushpull") } + let(:tracer) { double("logger") } + + context "when in server mode" do + it "a ‘bound’ info line is logged" do + allow(tracer).to receive(:debug) + output.logger = tracer + expect(tracer).to receive(:info).with("0mq: bound", {:address=>"tcp://127.0.0.1:2120"}) + output.register + output.do_close + end + end +end +``` + +To run this test: + +1. Open a terminal window +2. Navigate to the cloned plugin folder +3. The first time you run the test, run the command `bundle install` +4. Run the command `bundle exec rspec` + +Assuming all prerequisites were installed correctly, the test fails with output similar to: + +```shell +Using Accessor#strict_set for specs +Run options: exclude {:redis=>true, :socket=>true, :performance=>true, :couchdb=>true, :elasticsearch=>true, +:elasticsearch_secure=>true, :export_cypher=>true, :integration=>true, :windows=>true} + +LogStash::Outputs::ZeroMQ + when in server mode + a ‘bound’ info line is logged (FAILED - 1) + +Failures: + + 1) LogStash::Outputs::ZeroMQ when in server mode a ‘bound’ info line is logged + Failure/Error: output.register + Double "logger" received :info with unexpected arguments + expected: ("0mq: bound", {:address=>"tcp://127.0.0.1:2120"}) + got: ("0mq: connected", {:address=>"tcp://127.0.0.1:2120"}) + # ./lib/logstash/util/zeromq.rb:21:in `setup' + # ./lib/logstash/outputs/zeromq.rb:92:in `register' + # ./lib/logstash/outputs/zeromq.rb:91:in `register' + # ./spec/outputs/zeromq_spec.rb:13:in `(root)' + # /Users/guy/.gem/jruby/1.9.3/gems/rspec-wait-0.0.7/lib/rspec/wait.rb:46:in `(root)' + +Finished in 0.133 seconds (files took 1.28 seconds to load) +1 example, 1 failure + +Failed examples: + +rspec ./spec/outputs/zeromq_spec.rb:10 # LogStash::Outputs::ZeroMQ when in server mode a ‘bound’ info line is logged + +Randomized with seed 2568 +``` + +To correct the error, open the `util/zeromq.rb` file in your text editor and swap the positions of the words `connected` and `bound` on line 21. Line 21 now reads: + +```ruby +@logger.info("0mq: #{server? ? 'bound' : 'connected'}", :address => address) +``` + +Run the test again with the `bundle exec rspec` command. + +The test passes with output similar to: + +```shell +Using Accessor#strict_set for specs +Run options: exclude {:redis=>true, :socket=>true, :performance=>true, :couchdb=>true, :elasticsearch=>true, :elasticsearch_secure=>true, :export_cypher=>true, :integration=>true, :windows=>true} + +LogStash::Outputs::ZeroMQ + when in server mode + a ‘bound’ info line is logged + +Finished in 0.114 seconds (files took 1.22 seconds to load) +1 example, 0 failures + +Randomized with seed 45887 +``` + +[Commit](https://help.github.com/articles/fork-a-repo/#next-steps) the changes to git and Github. + +Your pull request is visible from the [Pull Requests](https://github.com/logstash-plugins/logstash-output-zeromq/pulls) section of the original Github repository. The plugin maintainers review your work, suggest changes if necessary, and merge and publish a new version of the plugin. + + diff --git a/docs/extend/create-logstash-plugins.md b/docs/extend/create-logstash-plugins.md new file mode 100644 index 000000000..7dc5d5ba5 --- /dev/null +++ b/docs/extend/create-logstash-plugins.md @@ -0,0 +1,47 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/contributing-java-plugin.html +--- + +# Create Logstash plugins [contributing-java-plugin] + +Now you can write your own Java plugin for use with {{ls}}. We have provided instructions and GitHub examples to give you a head start. + +Native support for Java plugins in {{ls}} consists of several components: + +* Extensions to the Java execution engine to support running Java plugins in Logstash pipelines +* APIs for developing Java plugins. The APIs are in the `co.elastic.logstash.api` package. A Java plugin might break if it references classes or specific concrete implementations of API interfaces outside that package. The implementation of classes outside of the API package may change at any time. +* Tooling to automate the packaging and deployment of Java plugins in Logstash. + + +## Process overview [_process_overview] + +Here are the steps: + +1. Choose the type of plugin you want to create: input, codec, filter, or output. +2. Set up your environment. +3. Code the plugin. +4. Package and deploy the plugin. +5. Run Logstash with your new plugin. + + +### Let’s get started [_lets_get_started] + +Here are the example repos: + +* [Input plugin example](https://github.com/logstash-plugins/logstash-input-java_input_example) +* [Codec plugin example](https://github.com/logstash-plugins/logstash-codec-java_codec_example) +* [Filter plugin example](https://github.com/logstash-plugins/logstash-filter-java_filter_example) +* [Output plugin example](https://github.com/logstash-plugins/logstash-output-java_output_example) + +Here are the instructions: + +* [How to write a Java input plugin](/extend/java-input-plugin.md) +* [How to write a Java codec plugin](/extend/java-codec-plugin.md) +* [How to write a Java filter plugin](/extend/java-filter-plugin.md) +* [How to write a Java output plugin](/extend/java-output-plugin.md) + + + + + diff --git a/docs/extend/filter-new-plugin.md b/docs/extend/filter-new-plugin.md new file mode 100644 index 000000000..0ea01f0ee --- /dev/null +++ b/docs/extend/filter-new-plugin.md @@ -0,0 +1,637 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/filter-new-plugin.html +--- + +# How to write a Logstash filter plugin [filter-new-plugin] + +To develop a new filter for Logstash, build a self-contained Ruby gem whose source code lives in its own GitHub repository. The Ruby gem can then be hosted and shared on RubyGems.org. You can use the example filter implementation as a starting point. (If you’re unfamiliar with Ruby, you can find an excellent quickstart guide at [https://www.ruby-lang.org/en/documentation/quickstart/](https://www.ruby-lang.org/en/documentation/quickstart/).) + +## Get started [_get_started_3] + +Let’s step through creating a filter plugin using the [example filter plugin](https://github.com/logstash-plugins/logstash-filter-example/). + +### Create a GitHub repo for your new plugin [_create_a_github_repo_for_your_new_plugin_3] + +Each Logstash plugin lives in its own GitHub repository. To create a new repository for your plugin: + +1. Log in to GitHub. +2. Click the **Repositories** tab. You’ll see a list of other repositories you’ve forked or contributed to. +3. Click the green **New** button in the upper right. +4. Specify the following settings for your new repo: + + * **Repository name** — a unique name of the form `logstash-filter-pluginname`. + * **Public or Private** — your choice, but the repository must be Public if you want to submit it as an official plugin. + * **Initialize this repository with a README** — enables you to immediately clone the repository to your computer. + +5. Click **Create Repository**. + + +### Use the plugin generator tool [_use_the_plugin_generator_tool_3] + +You can create your own Logstash plugin in seconds! The `generate` subcommand of `bin/logstash-plugin` creates the foundation for a new Logstash plugin with templatized files. It creates the correct directory structure, gemspec files, and dependencies so you can start adding custom code to process data with Logstash. + +For more information, see [Generating plugins](/reference/plugin-generator.md) + + +### Copy the filter code [_copy_the_filter_code] + +Alternatively, you can use the examples repo we host on github.com + +1. **Clone your plugin.** Replace `GITUSERNAME` with your github username, and `MYPLUGINNAME` with your plugin name. + + * `git clone https://github.com/GITUSERNAME/logstash-``filter-MYPLUGINNAME.git` + + * alternately, via ssh: `git clone git@github.com:GITUSERNAME/logstash``-filter-MYPLUGINNAME.git` + + * `cd logstash-filter-MYPLUGINNAME` + +2. **Clone the filter plugin example and copy it to your plugin branch.** + + You don’t want to include the example .git directory or its contents, so delete it before you copy the example. + + * `cd /tmp` + * `git clone https://github.com/logstash-plugins/logstash``-filter-example.git` + * `cd logstash-filter-example` + * `rm -rf .git` + * `cp -R * /path/to/logstash-filter-mypluginname/` + +3. **Rename the following files to match the name of your plugin.** + + * `logstash-filter-example.gemspec` + * `example.rb` + * `example_spec.rb` + + ```txt + cd /path/to/logstash-filter-mypluginname + mv logstash-filter-example.gemspec logstash-filter-mypluginname.gemspec + mv lib/logstash/filters/example.rb lib/logstash/filters/mypluginname.rb + mv spec/filters/example_spec.rb spec/filters/mypluginname_spec.rb + ``` + + +Your file structure should look like this: + +```txt +$ tree logstash-filter-mypluginname +├── Gemfile +├── LICENSE +├── README.md +├── Rakefile +├── lib +│   └── logstash +│   └── filters +│   └── mypluginname.rb +├── logstash-filter-mypluginname.gemspec +└── spec + └── filters + └── mypluginname_spec.rb +``` + +For more information about the Ruby gem file structure and an excellent walkthrough of the Ruby gem creation process, see [http://timelessrepo.com/making-ruby-gems](http://timelessrepo.com/making-ruby-gems) + + +### See what your plugin looks like [_see_what_your_plugin_looks_like_3] + +Before we dive into the details, open up the plugin file in your favorite text editor and take a look. + +```ruby +require "logstash/filters/base" +require "logstash/namespace" + +# Add any asciidoc formatted documentation here +# This example filter will replace the contents of the default +# message field with whatever you specify in the configuration. +# +# It is only intended to be used as an example. +class LogStash::Filters::Example < LogStash::Filters::Base + + # Setting the config_name here is required. This is how you + # configure this filter from your Logstash config. + # + # filter { + # example { message => "My message..." } + # } + config_name "example" + + # Replace the message with this value. + config :message, :validate => :string, :default => "Hello World!" + + + public + def register + # Add instance variables + end # def register + + public + def filter(event) + + if @message + # Replace the event message with our message as configured in the + # config file. + event.set("message", @message) + end + + # filter_matched should go in the last line of our successful code + filter_matched(event) + end # def filter + +end # class LogStash::Filters::Example +``` + + + +## Coding filter plugins [_coding_filter_plugins] + +Now let’s take a line-by-line look at the example plugin. + +### `require` Statements [_require_statements_3] + +Logstash filter plugins require parent classes defined in `logstash/filters/base` and logstash/namespace: + +```ruby +require "logstash/filters/base" +require "logstash/namespace" +``` + +Of course, the plugin you build may depend on other code, or even gems. Just put them here along with these Logstash dependencies. + + + +## Plugin Body [_plugin_body_3] + +Let’s go through the various elements of the plugin itself. + +### `class` Declaration [_class_declaration_3] + +The filter plugin class should be a subclass of `LogStash::Filters::Base`: + +```ruby +class LogStash::Filters::Example < LogStash::Filters::Base +``` + +The class name should closely mirror the plugin name, for example: + +```ruby +LogStash::Filters::Example +``` + + +### `config_name` [_config_name_3] + +```ruby + config_name "example" +``` + +This is the name your plugin will call inside the filter configuration block. + +If you set `config_name "example"` in your plugin code, the corresponding Logstash configuration block would need to look like this: + + + +## Configuration Parameters [_configuration_parameters_3] + +```ruby + config :variable_name, :validate => :variable_type, :default => "Default value", :required => boolean, :deprecated => boolean, :obsolete => string +``` + +The configuration, or `config` section allows you to define as many (or as few) parameters as are needed to enable Logstash to process events. + +There are several configuration attributes: + +* `:validate` - allows you to enforce passing a particular data type to Logstash for this configuration option, such as `:string`, `:password`, `:boolean`, `:number`, `:array`, `:hash`, `:path` (a file-system path), `uri`, `:codec` (since 1.2.0), `:bytes`. Note that this also works as a coercion in that if I specify "true" for boolean (even though technically a string), it will become a valid boolean in the config. This coercion works for the `:number` type as well where "1.2" becomes a float and "22" is an integer. +* `:default` - lets you specify a default value for a parameter +* `:required` - whether or not this parameter is mandatory (a Boolean `true` or +* `:list` - whether or not this value should be a list of values. Will typecheck the list members, and convert scalars to one element lists. Note that this mostly obviates the array type, though if you need lists of complex objects that will be more suitable. `false`) +* `:deprecated` - informational (also a Boolean `true` or `false`) +* `:obsolete` - used to declare that a given setting has been removed and is no longer functioning. The idea is to provide an informed upgrade path to users who are still using a now-removed setting. + + +## Plugin Methods [_plugin_methods_3] + +Logstash filters must implement the `register` and `filter` methods. + +### `register` Method [_register_method_3] + +```ruby + public + def register + end # def register +``` + +The Logstash `register` method is like an `initialize` method. It was originally created to enforce having `super` called, preventing headaches for newbies. (Note: It may go away in favor of `initialize`, in conjunction with some enforced testing to ensure `super` is called.) + +`public` means the method can be called anywhere, not just within the class. This is the default behavior for methods in Ruby, but it is specified explicitly here anyway. + +You can also assign instance variables here (variables prepended by `@`). Configuration variables are now in scope as instance variables, like `@message` + + +### `filter` Method [_filter_method] + +```ruby + public + def filter(event) + + if @message + # Replace the event message with our message as configured in the + # config file. + event.set("message", @message) + end + + # filter_matched should go in the last line of our successful code + filter_matched(event) +end # def filter +``` + +The plugin’s `filter` method is where the actual filtering work takes place! Inside the `filter` method you can refer to the event data using the `Event` object. Event is the main object that encapsulates data flow internally in Logstash and provides an [API](/reference/event-api.md) for the plugin developers to interact with the event’s content. + +The `filter` method should also handle any [event dependent configuration](/reference/event-dependent-configuration.md) by explicitly calling the `sprintf` method available in Event class. For example: + +```ruby +field_foo = event.sprintf(field) +``` + +Note that configuration variables are now in scope as instance variables, like `@message` + +```ruby + filter_matched(event) +``` + +Calling the `filter_matched` method upon successful execution of the plugin will ensure that any fields or tags added through the Logstash configuration for this filter will be handled correctly. For example, any `add_field`, `remove_field`, `add_tag` and/or `remove_tag` actions will be performed at this time. + +Event methods such as `event.cancel` are now available to control the workflow of the event being processed. + + + +## Building the Plugin [_building_the_plugin_3] + +At this point in the process you have coded your plugin and are ready to build a Ruby Gem from it. The following information will help you complete the process. + +### External dependencies [_external_dependencies_3] + +A `require` statement in Ruby is used to include necessary code. In some cases your plugin may require additional files. For example, the collectd plugin [uses](https://github.com/logstash-plugins/logstash-codec-collectd/blob/main/lib/logstash/codecs/collectd.rb#L148) the `types.db` file provided by collectd. In the main directory of your plugin, a file called `vendor.json` is where these files are described. + +The `vendor.json` file contains an array of JSON objects, each describing a file dependency. This example comes from the [collectd](https://github.com/logstash-plugins/logstash-codec-collectd/blob/main/vendor.json) codec plugin: + +```txt +[{ + "sha1": "a90fe6cc53b76b7bdd56dc57950d90787cb9c96e", + "url": "http://collectd.org/files/collectd-5.4.0.tar.gz", + "files": [ "/src/types.db" ] +}] +``` + +* `sha1` is the sha1 signature used to verify the integrity of the file referenced by `url`. +* `url` is the address from where Logstash will download the file. +* `files` is an optional array of files to extract from the downloaded file. Note that while tar archives can use absolute or relative paths, treat them as absolute in this array. If `files` is not present, all files will be uncompressed and extracted into the vendor directory. + +Another example of the `vendor.json` file is the [`geoip` filter](https://github.com/logstash-plugins/logstash-filter-geoip/blob/main/vendor.json) + +The process used to download these dependencies is to call `rake vendor`. This will be discussed further in the testing section of this document. + +Another kind of external dependency is on jar files. This will be described in the "Add a `gemspec` file" section. + + +### Deprecated features [_deprecated_features_3] + +As a plugin evolves, an option or feature may no longer serve the intended purpose, and the developer may want to *deprecate* its usage. Deprecation warns users about the option’s status, so they aren’t caught by surprise when it is removed in a later release. + +{{ls}} 7.6 introduced a *deprecation logger* to make handling those situations easier. You can use the [adapter](https://github.com/logstash-plugins/logstash-mixin-deprecation_logger_support) to ensure that your plugin can use the deprecation logger while still supporting older versions of {{ls}}. See the [readme](https://github.com/logstash-plugins/logstash-mixin-deprecation_logger_support/blob/main/README.md) for more information and for instructions on using the adapter. + +Deprecations are noted in the `logstash-deprecation.log` file in the `log` directory. + + +### Add a Gemfile [_add_a_gemfile_3] + +Gemfiles allow Ruby’s Bundler to maintain the dependencies for your plugin. Currently, all we’ll need is the Logstash gem, for testing, but if you require other gems, you should add them in here. + +::::{tip} +See [Bundler’s Gemfile page](http://bundler.io/gemfile.html) for more details. +:::: + + +```ruby +source 'https://rubygems.org' +gemspec +gem "logstash", :github => "elastic/logstash", :branch => "master" +``` + + + +## Add a `gemspec` file [_add_a_gemspec_file_3] + +Gemspecs define the Ruby gem which will be built and contain your plugin. + +::::{tip} +More information can be found on the [Rubygems Specification page](http://guides.rubygems.org/specification-reference/). +:::: + + +```ruby +Gem::Specification.new do |s| + s.name = 'logstash-filter-example' + s.version = '0.1.0' + s.licenses = ['Apache License (2.0)'] + s.summary = "This filter does x, y, z in Logstash" + s.description = "This gem is a logstash plugin required to be installed on top of the Logstash core pipeline using $LS_HOME/bin/logstash-plugin install gemname. This gem is not a stand-alone program" + s.authors = ["Elastic"] + s.email = 'info@elastic.co' + s.homepage = "http://www.elastic.co/guide/en/logstash/current/index.html" + s.require_paths = ["lib"] + + # Files + s.files = Dir['lib/**/*','spec/**/*','vendor/**/*','*.gemspec','*.md','CONTRIBUTORS','Gemfile','LICENSE','NOTICE.TXT'] + # Tests + s.test_files = s.files.grep(%r{^(test|spec|features)/}) + + # Special flag to let us know this is actually a logstash plugin + s.metadata = { "logstash_plugin" => "true", "logstash_group" => "filter" } + + # Gem dependencies + s.add_runtime_dependency "logstash-core-plugin-api", ">= 1.60", "<= 2.99" + s.add_development_dependency 'logstash-devutils' +end +``` + +It is appropriate to change these values to fit your plugin. In particular, `s.name` and `s.summary` should reflect your plugin’s name and behavior. + +`s.licenses` and `s.version` are also important and will come into play when you are ready to publish your plugin. + +Logstash and all its plugins are licensed under [Apache License, version 2 ("ALv2")](https://github.com/elastic/logstash/blob/main/LICENSE.txt). If you make your plugin publicly available via [RubyGems.org](http://rubygems.org), please make sure to have this line in your gemspec: + +* `s.licenses = ['Apache License (2.0)']` + +The gem version, designated by `s.version`, helps track changes to plugins over time. You should use [semver versioning](http://semver.org/) strategy for version numbers. + +### Runtime and Development Dependencies [_runtime_and_development_dependencies_3] + +At the bottom of the `gemspec` file is a section with a comment: `Gem dependencies`. This is where any other needed gems must be mentioned. If a gem is necessary for your plugin to function, it is a runtime dependency. If a gem are only used for testing, then it would be a development dependency. + +::::{note} +You can also have versioning requirements for your dependencies—​including other Logstash plugins: + +```ruby + # Gem dependencies + s.add_runtime_dependency "logstash-core-plugin-api", ">= 1.60", "<= 2.99" + s.add_development_dependency 'logstash-devutils' +``` + +This gemspec has a runtime dependency on the logstash-core-plugin-api and requires that it have a version number greater than or equal to version 1.60 and less than or equal to version 2.99. + +:::: + + +::::{important} +All plugins have a runtime dependency on the `logstash-core-plugin-api` gem, and a development dependency on `logstash-devutils`. +:::: + + + +### Jar dependencies [_jar_dependencies_3] + +In some cases, such as the [Elasticsearch output plugin](https://github.com/logstash-plugins/logstash-output-elasticsearch/blob/main/logstash-output-elasticsearch.gemspec#L22-L23), your code may depend on a jar file. In cases such as this, the dependency is added in the gemspec file in this manner: + +```ruby + # Jar dependencies + s.requirements << "jar 'org.elasticsearch:elasticsearch', '5.0.0'" + s.add_runtime_dependency 'jar-dependencies' +``` + +With these both defined, the install process will search for the required jar file at [http://mvnrepository.com](http://mvnrepository.com) and download the specified version. + + + +## Document your plugin [_document_your_plugin_3] + +Documentation is an important part of your plugin. All plugin documentation is rendered and placed in the [Logstash Reference](/reference/index.md) and the [Versioned plugin docs](logstash-docs://reference/integration-plugins.md). + +See [Document your plugin](/extend/plugin-doc.md) for tips and guidelines. + + +## Add Tests [_add_tests_3] + +Logstash loves tests. Lots of tests. If you’re using your new filter plugin in a production environment, you’ll want to have some tests to ensure you are not breaking any existing functionality. + +::::{note} +A full exposition on RSpec is outside the scope of this document. Learn more about RSpec at [http://rspec.info](http://rspec.info) +:::: + + +For help learning about tests and testing, look in the `spec/filters/` directory of several other similar plugins. + + +## Clone and test! [_clone_and_test_3] + +Now let’s start with a fresh clone of the plugin, build it and run the tests. + +* **Clone your plugin into a temporary location** Replace `GITUSERNAME` with your github username, and `MYPLUGINNAME` with your plugin name. + + * `git clone https://github.com/GITUSERNAME/logstash-``filter-MYPLUGINNAME.git` + + * alternately, via ssh: `git clone git@github.com:GITUSERNAME/logstash-``filter-MYPLUGINNAME.git` + + * `cd logstash-filter-MYPLUGINNAME` + + +Then, you’ll need to install your plugins dependencies with bundler: + +``` +bundle install +``` + +::::{important} +If your plugin has an external file dependency described in `vendor.json`, you must download that dependency before running or testing. You can do this by running: + +``` +rake vendor +``` + +:::: + + +And finally, run the tests: + +``` +bundle exec rspec +``` + +You should see a success message, which looks something like this: + +``` +Finished in 0.034 seconds +1 example, 0 failures +``` + +Hooray! You’re almost there! (Unless you saw failures…​ you should fix those first). + + +## Building and Testing [_building_and_testing_3] + +Now you’re ready to build your (well-tested) plugin into a Ruby gem. + +### Build [_build_3] + +You already have all the necessary ingredients, so let’s go ahead and run the build command: + +```sh +gem build logstash-filter-example.gemspec +``` + +That’s it! Your gem should be built and be in the same path with the name + +```sh +logstash-filter-mypluginname-0.1.0.gem +``` + +The `s.version` number from your gemspec file will provide the gem version, in this case, `0.1.0`. + + +### Test installation [_test_installation_3] + +You should test install your plugin into a clean installation of Logstash. Download the latest version from the [Logstash downloads page](https://www.elastic.co/downloads/logstash/). + +1. Untar and cd in to the directory: + + ```sh + curl -O https://download.elastic.co/logstash/logstash/logstash-9.0.0.tar.gz + tar xzvf logstash-9.0.0.tar.gz + cd logstash-9.0.0 + ``` + +2. Using the plugin tool, we can install the gem we just built. + + * Replace `/my/logstash/plugins` with the correct path to the gem for your environment, and `0.1.0` with the correct version number from the gemspec file. + + ```sh + bin/logstash-plugin install /my/logstash/plugins/logstash-filter-example/logstash-filter-example-0.1.0.gem + ``` + + * After running this, you should see feedback from Logstash that it was successfully installed: + + ```sh + validating /my/logstash/plugins/logstash-filter-example/logstash-filter-example-0.1.0.gem >= 0 + Valid logstash plugin. Continuing... + Successfully installed 'logstash-filter-example' with version '0.1.0' + ``` + + ::::{tip} + You can also use the Logstash plugin tool to determine which plugins are currently available: + + ```sh + bin/logstash-plugin list + ``` + + Depending on what you have installed, you might see a short or long list of plugins: inputs, codecs, filters and outputs. + + :::: + +3. Now try running Logstash with a simple configuration passed in via the command-line, using the `-e` flag. + + ::::{note} + Your results will depend on what your filter plugin is designed to do. + :::: + + +```sh +bin/logstash -e 'input { stdin{} } filter { example {} } output {stdout { codec => rubydebug }}' +``` + +Test your filter by sending input through `stdin` and output (after filtering) through `stdout` with the `rubydebug` codec, which enhances readability. + +In the case of the example filter plugin, any text you send will be replaced by the contents of the `message` configuration parameter, the default value being "Hello World!": + +```sh +Testing 1, 2, 3 +{ + "message" => "Hello World!", + "@version" => "1", + "@timestamp" => "2015-01-27T19:17:18.932Z", + "host" => "cadenza" +} +``` + +Feel free to experiment and test this by changing the `message` parameter: + +```sh +bin/logstash -e 'input { stdin{} } filter { example { message => "This is a new message!"} } output {stdout { codec => rubydebug }}' +``` + +Congratulations! You’ve built, deployed and successfully run a Logstash filter. + + + +## Submitting your plugin to [RubyGems.org](http://rubygems.org) and [logstash-plugins](https://github.com/logstash-plugins) [_submitting_your_plugin_to_rubygems_orghttprubygems_org_and_logstash_pluginshttpsgithub_comlogstash_plugins_3] + +Logstash uses [RubyGems.org](http://rubygems.org) as its repository for all plugin artifacts. Once you have developed your new plugin, you can make it available to Logstash users by simply publishing it to RubyGems.org. + +### Licensing [_licensing_3] + +Logstash and all its plugins are licensed under [Apache License, version 2 ("ALv2")](https://github.com/elasticsearch/logstash/blob/main/LICENSE). If you make your plugin publicly available via [RubyGems.org](http://rubygems.org), please make sure to have this line in your gemspec: + +* `s.licenses = ['Apache License (2.0)']` + + +### Publishing to [RubyGems.org](http://rubygems.org) [_publishing_to_rubygems_orghttprubygems_org_3] + +To begin, you’ll need an account on RubyGems.org + +* [Sign-up for a RubyGems account](https://rubygems.org/sign_up). + +After creating an account, [obtain](http://guides.rubygems.org/rubygems-org-api/#api-authorization) an API key from RubyGems.org. By default, RubyGems uses the file `~/.gem/credentials` to store your API key. These credentials will be used to publish the gem. Replace `username` and `password` with the credentials you created at RubyGems.org: + +```sh +curl -u username:password https://rubygems.org/api/v1/api_key.yaml > ~/.gem/credentials +chmod 0600 ~/.gem/credentials +``` + +Before proceeding, make sure you have the right version in your gemspec file and commit your changes. + +* `s.version = '0.1.0'` + +To publish version 0.1.0 of your new logstash gem: + +```sh +bundle install +bundle exec rake vendor +bundle exec rspec +bundle exec rake publish_gem +``` + +::::{note} +Executing `rake publish_gem`: + +1. Reads the version from the gemspec file (`s.version = '0.1.0'`) +2. Checks in your local repository if a tag exists for that version. If the tag already exists, it aborts the process. Otherwise, it creates a new version tag in your local repository. +3. Builds the gem +4. Publishes the gem to RubyGems.org + +:::: + + +That’s it! Your plugin is published! Logstash users can now install your plugin by running: + +```sh +bin/logstash-plugin install logstash-filter-mypluginname +``` + + + +## Contributing your source code to [logstash-plugins](https://github.com/logstash-plugins) [_contributing_your_source_code_to_logstash_pluginshttpsgithub_comlogstash_plugins_3] + +It is not required to contribute your source code to [logstash-plugins](https://github.com/logstash-plugins) github organization, but we always welcome new plugins! + +### Benefits [_benefits_3] + +Some of the many benefits of having your plugin in the logstash-plugins repository are: + +* **Discovery.** Your plugin will appear in the [Logstash Reference](/reference/index.md), where Logstash users look first for plugins and documentation. +* **Documentation.** Your plugin documentation will automatically be added to the [Logstash Reference](/reference/index.md). +* **Testing.** With our testing infrastructure, your plugin will be continuously tested against current and future releases of Logstash. As a result, users will have the assurance that if incompatibilities arise, they will be quickly discovered and corrected. + + +### Acceptance Guidelines [_acceptance_guidelines_3] + +* **Code Review.** Your plugin must be reviewed by members of the community for coherence, quality, readability, stability and security. +* **Tests.** Your plugin must contain tests to be accepted. These tests are also subject to code review for scope and completeness. It’s ok if you don’t know how to write tests — we will guide you. We are working on publishing a guide to creating tests for Logstash which will make it easier. In the meantime, you can refer to [http://betterspecs.org/](http://betterspecs.org/) for examples. + +To begin migrating your plugin to logstash-plugins, simply create a new [issue](https://github.com/elasticsearch/logstash/issues) in the Logstash repository. When the acceptance guidelines are completed, we will facilitate the move to the logstash-plugins organization using the recommended [github process](https://help.github.com/articles/transferring-a-repository/#transferring-from-a-user-to-an-organization). diff --git a/docs/extend/index.md b/docs/extend/index.md new file mode 100644 index 000000000..f4ed32f89 --- /dev/null +++ b/docs/extend/index.md @@ -0,0 +1,58 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/contributing-to-logstash.html +--- + +# Contributing to Logstash [contributing-to-logstash] + +You can add your own input, codec, filter, or output plugins to Logstash. + + +### Acceptance guidelines [plugin-acceptance] + +Start with the end in mind. These guidelines and best practices can help you build a better plugin, even if you choose not to share it with the world. + +* **Consistency.** Your plugin must be consistent in quality and naming conventions used by other plugins. The plugin name must be unique and in this format: `logstash-plugintype-pluginname`. If the plugin name is more than one word, separate words after plugin type with underscores. Example: *logstash-output-elastic_app_search* +* **Documentation.** Documentation is a required component of your plugin. If we list your plugin in the Logstash Reference, we point to your documentation—​a readme.md, docs/index.asciidoc, or both—​in your plugin repo. +* **Code Review.** Your plugin must be reviewed by members of the community for coherence, quality, readability, stability and security. +* **Tests.** Your plugin must contain tests to be accepted. You can refer to [http://betterspecs.org/](http://betterspecs.org/) for examples. + + * Step 1. Enable travis on your account + * Step 2. Import our standard travis.yml [https://github.com/logstash-plugins/.ci/blob/1.x/travis/travis.yml](https://github.com/logstash-plugins/.ci/blob/1.x/travis/travis.yml), as shown in the [fingerprint filter example](https://github.com/logstash-plugins/logstash-filter-fingerprint/blob/main/.travis.yml). + * Step 3. Have specs in the spec folder. + + + +## Add a plugin [add-plugin] + +Plugins can be developed and deployed independently of the Logstash core. Here are some documents to guide you through the process of coding, deploying, and sharing your plugin: + +* Write a new plugin + + * [How to write a Logstash input plugin](/extend/input-new-plugin.md) + * [How to write a Logstash codec plugin](/extend/codec-new-plugin.md) + * [How to write a Logstash filter plugin](/extend/filter-new-plugin.md) + * [How to write a Logstash output plugin](/extend/output-new-plugin.md) + * [Community Maintainer’s Guide](/extend/community-maintainer.md) + +* [Document your plugin](/extend/plugin-doc.md) +* [Publish your plugin to RubyGems.org](/extend/publish-plugin.md) +* [List your plugin](/extend/plugin-listing.md) +* Contribute a patch + + * [Contributing a patch to a Logstash plugin](/extend/contributing-patch-plugin.md) + * [Extending Logstash core](/extend/contribute-to-core.md) + + + +#### Plugin Shutdown APIs [shutdown-apis] + +You have three options for shutting down a plugin: `stop`, `stop?`, and `close`. + +* Call the `stop` method from outside the plugin thread. This method signals the plugin to stop. +* The `stop?` method returns `true` when the `stop` method has already been called for that plugin. +* The `close` method performs final bookkeeping and cleanup after the plugin’s `run` method and the plugin’s thread both exit. The `close` method is a a new name for the method known as `teardown` in previous versions of Logstash. + +The `shutdown`, `finished`, `finished?`, `running?`, and `terminating?` methods are redundant and no longer present in the Plugin Base class. + +Sample code for the plugin shutdown APIs is [available](https://github.com/logstash-plugins/logstash-input-example/blob/main/lib/logstash/inputs/example.rb). diff --git a/docs/extend/input-new-plugin.md b/docs/extend/input-new-plugin.md new file mode 100644 index 000000000..c42daac4e --- /dev/null +++ b/docs/extend/input-new-plugin.md @@ -0,0 +1,674 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/input-new-plugin.html +--- + +# How to write a Logstash input plugin [input-new-plugin] + +To develop a new input for Logstash, build a self-contained Ruby gem whose source code lives in its own GitHub repository. The Ruby gem can then be hosted and shared on RubyGems.org. You can use the example input implementation as a starting point. (If you’re unfamiliar with Ruby, you can find an excellent quickstart guide at [https://www.ruby-lang.org/en/documentation/quickstart/](https://www.ruby-lang.org/en/documentation/quickstart/).) + +## Get started [_get_started] + +Let’s step through creating an input plugin using the [example input plugin](https://github.com/logstash-plugins/logstash-input-example/). + +### Create a GitHub repo for your new plugin [_create_a_github_repo_for_your_new_plugin] + +Each Logstash plugin lives in its own GitHub repository. To create a new repository for your plugin: + +1. Log in to GitHub. +2. Click the **Repositories** tab. You’ll see a list of other repositories you’ve forked or contributed to. +3. Click the green **New** button in the upper right. +4. Specify the following settings for your new repo: + + * **Repository name** — a unique name of the form `logstash-input-pluginname`. + * **Public or Private** — your choice, but the repository must be Public if you want to submit it as an official plugin. + * **Initialize this repository with a README** — enables you to immediately clone the repository to your computer. + +5. Click **Create Repository**. + + +### Use the plugin generator tool [_use_the_plugin_generator_tool] + +You can create your own Logstash plugin in seconds! The `generate` subcommand of `bin/logstash-plugin` creates the foundation for a new Logstash plugin with templatized files. It creates the correct directory structure, gemspec files, and dependencies so you can start adding custom code to process data with Logstash. + +For more information, see [Generating plugins](/reference/plugin-generator.md) + + +### Copy the input code [_copy_the_input_code] + +Alternatively, you can use the examples repo we host on github.com + +1. **Clone your plugin.** Replace `GITUSERNAME` with your github username, and `MYPLUGINNAME` with your plugin name. + + * `git clone https://github.com/GITUSERNAME/logstash-``input-MYPLUGINNAME.git` + + * alternately, via ssh: `git clone git@github.com:GITUSERNAME/logstash``-input-MYPLUGINNAME.git` + + * `cd logstash-input-MYPLUGINNAME` + +2. **Clone the input plugin example and copy it to your plugin branch.** + + You don’t want to include the example .git directory or its contents, so delete it before you copy the example. + + * `cd /tmp` + * `git clone https://github.com/logstash-plugins/logstash``-input-example.git` + * `cd logstash-input-example` + * `rm -rf .git` + * `cp -R * /path/to/logstash-input-mypluginname/` + +3. **Rename the following files to match the name of your plugin.** + + * `logstash-input-example.gemspec` + * `example.rb` + * `example_spec.rb` + + ```txt + cd /path/to/logstash-input-mypluginname + mv logstash-input-example.gemspec logstash-input-mypluginname.gemspec + mv lib/logstash/inputs/example.rb lib/logstash/inputs/mypluginname.rb + mv spec/inputs/example_spec.rb spec/inputs/mypluginname_spec.rb + ``` + + +Your file structure should look like this: + +```txt +$ tree logstash-input-mypluginname +├── Gemfile +├── LICENSE +├── README.md +├── Rakefile +├── lib +│   └── logstash +│   └── inputs +│   └── mypluginname.rb +├── logstash-input-mypluginname.gemspec +└── spec + └── inputs + └── mypluginname_spec.rb +``` + +For more information about the Ruby gem file structure and an excellent walkthrough of the Ruby gem creation process, see [http://timelessrepo.com/making-ruby-gems](http://timelessrepo.com/making-ruby-gems) + + +### See what your plugin looks like [_see_what_your_plugin_looks_like] + +Before we dive into the details, open up the plugin file in your favorite text editor and take a look. + +```ruby +require "logstash/inputs/base" +require "logstash/namespace" +require "stud/interval" +require "socket" # for Socket.gethostname + +# Add any asciidoc formatted documentation here +# Generate a repeating message. +# +# This plugin is intended only as an example. + +class LogStash::Inputs::Example < LogStash::Inputs::Base + config_name "example" + + # If undefined, Logstash will complain, even if codec is unused. + default :codec, "plain" + + # The message string to use in the event. + config :message, :validate => :string, :default => "Hello World!" + + # Set how frequently messages should be sent. + # + # The default, `1`, means send a message every second. + config :interval, :validate => :number, :default => 1 + + public + def register + @host = Socket.gethostname + end # def register + + def run(queue) + Stud.interval(@interval) do + event = LogStash::Event.new("message" => @message, "host" => @host) + decorate(event) + queue << event + end # loop + end # def run + +end # class LogStash::Inputs::Example +``` + + + +## Coding input plugins [_coding_input_plugins] + +Now let’s take a line-by-line look at the example plugin. + +### `require` Statements [_require_statements] + +Logstash input plugins require parent classes defined in `logstash/inputs/base` and logstash/namespace: + +```ruby +require "logstash/inputs/base" +require "logstash/namespace" +``` + +Of course, the plugin you build may depend on other code, or even gems. Just put them here along with these Logstash dependencies. + + + +## Plugin Body [_plugin_body] + +Let’s go through the various elements of the plugin itself. + +### `class` Declaration [_class_declaration] + +The input plugin class should be a subclass of `LogStash::Inputs::Base`: + +```ruby +class LogStash::Inputs::Example < LogStash::Inputs::Base +``` + +The class name should closely mirror the plugin name, for example: + +```ruby +LogStash::Inputs::Example +``` + + +### `config_name` [_config_name] + +```ruby + config_name "example" +``` + +This is the name your plugin will call inside the input configuration block. + +If you set `config_name "example"` in your plugin code, the corresponding Logstash configuration block would need to look like this: + +```js +input { + example {...} +} +``` + + + +## Configuration Parameters [_configuration_parameters] + +```ruby + config :variable_name, :validate => :variable_type, :default => "Default value", :required => boolean, :deprecated => boolean, :obsolete => string +``` + +The configuration, or `config` section allows you to define as many (or as few) parameters as are needed to enable Logstash to process events. + +There are several configuration attributes: + +* `:validate` - allows you to enforce passing a particular data type to Logstash for this configuration option, such as `:string`, `:password`, `:boolean`, `:number`, `:array`, `:hash`, `:path` (a file-system path), `uri`, `:codec` (since 1.2.0), `:bytes`. Note that this also works as a coercion in that if I specify "true" for boolean (even though technically a string), it will become a valid boolean in the config. This coercion works for the `:number` type as well where "1.2" becomes a float and "22" is an integer. +* `:default` - lets you specify a default value for a parameter +* `:required` - whether or not this parameter is mandatory (a Boolean `true` or +* `:list` - whether or not this value should be a list of values. Will typecheck the list members, and convert scalars to one element lists. Note that this mostly obviates the array type, though if you need lists of complex objects that will be more suitable. `false`) +* `:deprecated` - informational (also a Boolean `true` or `false`) +* `:obsolete` - used to declare that a given setting has been removed and is no longer functioning. The idea is to provide an informed upgrade path to users who are still using a now-removed setting. + + +## Plugin Methods [_plugin_methods] + +Logstash inputs must implement two main methods: `register` and `run`. + +### `register` Method [_register_method] + +```ruby + public + def register + end # def register +``` + +The Logstash `register` method is like an `initialize` method. It was originally created to enforce having `super` called, preventing headaches for newbies. (Note: It may go away in favor of `initialize`, in conjunction with some enforced testing to ensure `super` is called.) + +`public` means the method can be called anywhere, not just within the class. This is the default behavior for methods in Ruby, but it is specified explicitly here anyway. + +You can also assign instance variables here (variables prepended by `@`). Configuration variables are now in scope as instance variables, like `@message` + + +### `run` Method [_run_method] + +The example input plugin has the following `run` Method: + +```ruby + def run(queue) + Stud.interval(@interval) do + event = LogStash::Event.new("message" => @message, "host" => @host) + decorate(event) + queue << event + end # loop + end # def run +``` + +The `run` method is where a stream of data from an input becomes an event. + +The stream can be plain or generated as with the [heartbeat](https://github.com/logstash-plugins/logstash-input-heartbeat/blob/main/lib/logstash/inputs/heartbeat.rb#L43-L61) input plugin. In these cases, though no codec is used, [a default codec](https://github.com/logstash-plugins/logstash-input-heartbeat/blob/main/lib/logstash/inputs/heartbeat.rb#L17) must be set in the code to avoid errors. + +Here’s another example `run` method: + +```ruby + def run(queue) + while true + begin + # Based on some testing, there is no way to interrupt an IO.sysread nor + # IO.select call in JRuby. + data = $stdin.sysread(16384) + @codec.decode(data) do |event| + decorate(event) + event.set("host", @host) if !event.include?("host") + queue << event + end + rescue IOError, EOFError, LogStash::ShutdownSignal + # stdin closed or a requested shutdown + break + end + end # while true + finished + end # def run +``` + +In this example, the `data` is being sent to the codec defined in the configuration block to `decode` the data stream and return an event. + +In both examples, the resulting `event` is passed to the `decorate` method: + +```ruby + decorate(event) +``` + +This applies any tags you might have set in the input configuration block. For example, `tags => ["tag1", "tag2"]`. + +Also in both examples, the `event`, after being "decorated," is appended to the queue: + +```ruby + queue << event +``` + +This inserts the event into the pipeline. + +::::{tip} +Because input plugins can range from simple to complex, it is helpful to see more examples of how they have been created: + +* [syslog](https://github.com/logstash-plugins/logstash-input-syslog/blob/main/lib/logstash/inputs/syslog.rb) +* [zeromq](https://github.com/logstash-plugins/logstash-input-zeromq/blob/main/lib/logstash/inputs/zeromq.rb) +* [stdin](https://github.com/logstash-plugins/logstash-input-stdin/blob/main/lib/logstash/inputs/stdin.rb) +* [tcp](https://github.com/logstash-plugins/logstash-input-tcp/blob/main/lib/logstash/inputs/tcp.rb) + +There are many more more examples in the [logstash-plugin github repository](https://github.com/logstash-plugins?query=logstash-input). + +:::: + + + + +## Building the Plugin [_building_the_plugin] + +At this point in the process you have coded your plugin and are ready to build a Ruby Gem from it. The following information will help you complete the process. + +### External dependencies [_external_dependencies] + +A `require` statement in Ruby is used to include necessary code. In some cases your plugin may require additional files. For example, the collectd plugin [uses](https://github.com/logstash-plugins/logstash-codec-collectd/blob/main/lib/logstash/codecs/collectd.rb#L148) the `types.db` file provided by collectd. In the main directory of your plugin, a file called `vendor.json` is where these files are described. + +The `vendor.json` file contains an array of JSON objects, each describing a file dependency. This example comes from the [collectd](https://github.com/logstash-plugins/logstash-codec-collectd/blob/main/vendor.json) codec plugin: + +```txt +[{ + "sha1": "a90fe6cc53b76b7bdd56dc57950d90787cb9c96e", + "url": "http://collectd.org/files/collectd-5.4.0.tar.gz", + "files": [ "/src/types.db" ] +}] +``` + +* `sha1` is the sha1 signature used to verify the integrity of the file referenced by `url`. +* `url` is the address from where Logstash will download the file. +* `files` is an optional array of files to extract from the downloaded file. Note that while tar archives can use absolute or relative paths, treat them as absolute in this array. If `files` is not present, all files will be uncompressed and extracted into the vendor directory. + +Another example of the `vendor.json` file is the [`geoip` filter](https://github.com/logstash-plugins/logstash-filter-geoip/blob/main/vendor.json) + +The process used to download these dependencies is to call `rake vendor`. This will be discussed further in the testing section of this document. + +Another kind of external dependency is on jar files. This will be described in the "Add a `gemspec` file" section. + + +### Deprecated features [_deprecated_features] + +As a plugin evolves, an option or feature may no longer serve the intended purpose, and the developer may want to *deprecate* its usage. Deprecation warns users about the option’s status, so they aren’t caught by surprise when it is removed in a later release. + +{{ls}} 7.6 introduced a *deprecation logger* to make handling those situations easier. You can use the [adapter](https://github.com/logstash-plugins/logstash-mixin-deprecation_logger_support) to ensure that your plugin can use the deprecation logger while still supporting older versions of {{ls}}. See the [readme](https://github.com/logstash-plugins/logstash-mixin-deprecation_logger_support/blob/main/README.md) for more information and for instructions on using the adapter. + +Deprecations are noted in the `logstash-deprecation.log` file in the `log` directory. + + +### Add a Gemfile [_add_a_gemfile] + +Gemfiles allow Ruby’s Bundler to maintain the dependencies for your plugin. Currently, all we’ll need is the Logstash gem, for testing, but if you require other gems, you should add them in here. + +::::{tip} +See [Bundler’s Gemfile page](http://bundler.io/gemfile.html) for more details. +:::: + + +```ruby +source 'https://rubygems.org' +gemspec +gem "logstash", :github => "elastic/logstash", :branch => "master" +``` + + + +## Add a `gemspec` file [_add_a_gemspec_file] + +Gemspecs define the Ruby gem which will be built and contain your plugin. + +::::{tip} +More information can be found on the [Rubygems Specification page](http://guides.rubygems.org/specification-reference/). +:::: + + +```ruby +Gem::Specification.new do |s| + s.name = 'logstash-input-example' + s.version = '0.1.0' + s.licenses = ['Apache License (2.0)'] + s.summary = "This input does x, y, z in Logstash" + s.description = "This gem is a logstash plugin required to be installed on top of the Logstash core pipeline using $LS_HOME/bin/logstash-plugin install gemname. This gem is not a stand-alone program" + s.authors = ["Elastic"] + s.email = 'info@elastic.co' + s.homepage = "http://www.elastic.co/guide/en/logstash/current/index.html" + s.require_paths = ["lib"] + + # Files + s.files = Dir['lib/**/*','spec/**/*','vendor/**/*','*.gemspec','*.md','CONTRIBUTORS','Gemfile','LICENSE','NOTICE.TXT'] + # Tests + s.test_files = s.files.grep(%r{^(test|spec|features)/}) + + # Special flag to let us know this is actually a logstash plugin + s.metadata = { "logstash_plugin" => "true", "logstash_group" => "input" } + + # Gem dependencies + s.add_runtime_dependency "logstash-core-plugin-api", ">= 1.60", "<= 2.99" + s.add_development_dependency 'logstash-devutils' +end +``` + +It is appropriate to change these values to fit your plugin. In particular, `s.name` and `s.summary` should reflect your plugin’s name and behavior. + +`s.licenses` and `s.version` are also important and will come into play when you are ready to publish your plugin. + +Logstash and all its plugins are licensed under [Apache License, version 2 ("ALv2")](https://github.com/elastic/logstash/blob/main/LICENSE.txt). If you make your plugin publicly available via [RubyGems.org](http://rubygems.org), please make sure to have this line in your gemspec: + +* `s.licenses = ['Apache License (2.0)']` + +The gem version, designated by `s.version`, helps track changes to plugins over time. You should use [semver versioning](http://semver.org/) strategy for version numbers. + +### Runtime and Development Dependencies [_runtime_and_development_dependencies] + +At the bottom of the `gemspec` file is a section with a comment: `Gem dependencies`. This is where any other needed gems must be mentioned. If a gem is necessary for your plugin to function, it is a runtime dependency. If a gem are only used for testing, then it would be a development dependency. + +::::{note} +You can also have versioning requirements for your dependencies—​including other Logstash plugins: + +```ruby + # Gem dependencies + s.add_runtime_dependency "logstash-core-plugin-api", ">= 1.60", "<= 2.99" + s.add_development_dependency 'logstash-devutils' +``` + +This gemspec has a runtime dependency on the logstash-core-plugin-api and requires that it have a version number greater than or equal to version 1.60 and less than or equal to version 2.99. + +:::: + + +::::{important} +All plugins have a runtime dependency on the `logstash-core-plugin-api` gem, and a development dependency on `logstash-devutils`. +:::: + + + +### Jar dependencies [_jar_dependencies] + +In some cases, such as the [Elasticsearch output plugin](https://github.com/logstash-plugins/logstash-output-elasticsearch/blob/main/logstash-output-elasticsearch.gemspec#L22-L23), your code may depend on a jar file. In cases such as this, the dependency is added in the gemspec file in this manner: + +```ruby + # Jar dependencies + s.requirements << "jar 'org.elasticsearch:elasticsearch', '5.0.0'" + s.add_runtime_dependency 'jar-dependencies' +``` + +With these both defined, the install process will search for the required jar file at [http://mvnrepository.com](http://mvnrepository.com) and download the specified version. + + + +## Document your plugin [_document_your_plugin] + +Documentation is an important part of your plugin. All plugin documentation is rendered and placed in the [Logstash Reference](/reference/index.md) and the [Versioned plugin docs](logstash-docs://reference/integration-plugins.md). + +See [Document your plugin](/extend/plugin-doc.md) for tips and guidelines. + + +## Add Tests [_add_tests] + +Logstash loves tests. Lots of tests. If you’re using your new input plugin in a production environment, you’ll want to have some tests to ensure you are not breaking any existing functionality. + +::::{note} +A full exposition on RSpec is outside the scope of this document. Learn more about RSpec at [http://rspec.info](http://rspec.info) +:::: + + +For help learning about tests and testing, look in the `spec/inputs/` directory of several other similar plugins. + + +## Clone and test! [_clone_and_test] + +Now let’s start with a fresh clone of the plugin, build it and run the tests. + +* **Clone your plugin into a temporary location** Replace `GITUSERNAME` with your github username, and `MYPLUGINNAME` with your plugin name. + + * `git clone https://github.com/GITUSERNAME/logstash-``input-MYPLUGINNAME.git` + + * alternately, via ssh: `git clone git@github.com:GITUSERNAME/logstash-``input-MYPLUGINNAME.git` + + * `cd logstash-input-MYPLUGINNAME` + + +Then, you’ll need to install your plugins dependencies with bundler: + +``` +bundle install +``` + +::::{important} +If your plugin has an external file dependency described in `vendor.json`, you must download that dependency before running or testing. You can do this by running: + +``` +rake vendor +``` + +:::: + + +And finally, run the tests: + +``` +bundle exec rspec +``` + +You should see a success message, which looks something like this: + +``` +Finished in 0.034 seconds +1 example, 0 failures +``` + +Hooray! You’re almost there! (Unless you saw failures…​ you should fix those first). + + +## Building and Testing [_building_and_testing] + +Now you’re ready to build your (well-tested) plugin into a Ruby gem. + +### Build [_build] + +You already have all the necessary ingredients, so let’s go ahead and run the build command: + +```sh +gem build logstash-input-example.gemspec +``` + +That’s it! Your gem should be built and be in the same path with the name + +```sh +logstash-input-mypluginname-0.1.0.gem +``` + +The `s.version` number from your gemspec file will provide the gem version, in this case, `0.1.0`. + + +### Test installation [_test_installation] + +You should test install your plugin into a clean installation of Logstash. Download the latest version from the [Logstash downloads page](https://www.elastic.co/downloads/logstash/). + +1. Untar and cd in to the directory: + + ```sh + curl -O https://download.elastic.co/logstash/logstash/logstash-9.0.0.tar.gz + tar xzvf logstash-9.0.0.tar.gz + cd logstash-9.0.0 + ``` + +2. Using the plugin tool, we can install the gem we just built. + + * Replace `/my/logstash/plugins` with the correct path to the gem for your environment, and `0.1.0` with the correct version number from the gemspec file. + + ```sh + bin/logstash-plugin install /my/logstash/plugins/logstash-input-example/logstash-input-example-0.1.0.gem + ``` + + * After running this, you should see feedback from Logstash that it was successfully installed: + + ```sh + validating /my/logstash/plugins/logstash-input-example/logstash-input-example-0.1.0.gem >= 0 + Valid logstash plugin. Continuing... + Successfully installed 'logstash-input-example' with version '0.1.0' + ``` + + ::::{tip} + You can also use the Logstash plugin tool to determine which plugins are currently available: + + ```sh + bin/logstash-plugin list + ``` + + Depending on what you have installed, you might see a short or long list of plugins: inputs, codecs, filters and outputs. + + :::: + +3. Now try running Logstash with a simple configuration passed in via the command-line, using the `-e` flag. + + ::::{note} + Your results will depend on what your input plugin is designed to do. + :::: + + +```sh +bin/logstash -e 'input { example{} } output {stdout { codec => rubydebug }}' +``` + +The example input plugin will send the contents of `message` (with a default message of "Hello World!") every second. + +```sh +{ + "message" => "Hello World!", + "@version" => "1", + "@timestamp" => "2015-01-27T19:17:18.932Z", + "host" => "cadenza" +} +``` + +Feel free to experiment and test this by changing the `message` and `interval` parameters: + +```sh +bin/logstash -e 'input { example{ message => "A different message" interval => 5 } } output {stdout { codec => rubydebug }}' +``` + +Congratulations! You’ve built, deployed and successfully run a Logstash input. + + + +## Submitting your plugin to [RubyGems.org](http://rubygems.org) and [logstash-plugins](https://github.com/logstash-plugins) [_submitting_your_plugin_to_rubygems_orghttprubygems_org_and_logstash_pluginshttpsgithub_comlogstash_plugins] + +Logstash uses [RubyGems.org](http://rubygems.org) as its repository for all plugin artifacts. Once you have developed your new plugin, you can make it available to Logstash users by simply publishing it to RubyGems.org. + +### Licensing [_licensing] + +Logstash and all its plugins are licensed under [Apache License, version 2 ("ALv2")](https://github.com/elasticsearch/logstash/blob/main/LICENSE). If you make your plugin publicly available via [RubyGems.org](http://rubygems.org), please make sure to have this line in your gemspec: + +* `s.licenses = ['Apache License (2.0)']` + + +### Publishing to [RubyGems.org](http://rubygems.org) [_publishing_to_rubygems_orghttprubygems_org] + +To begin, you’ll need an account on RubyGems.org + +* [Sign-up for a RubyGems account](https://rubygems.org/sign_up). + +After creating an account, [obtain](http://guides.rubygems.org/rubygems-org-api/#api-authorization) an API key from RubyGems.org. By default, RubyGems uses the file `~/.gem/credentials` to store your API key. These credentials will be used to publish the gem. Replace `username` and `password` with the credentials you created at RubyGems.org: + +```sh +curl -u username:password https://rubygems.org/api/v1/api_key.yaml > ~/.gem/credentials +chmod 0600 ~/.gem/credentials +``` + +Before proceeding, make sure you have the right version in your gemspec file and commit your changes. + +* `s.version = '0.1.0'` + +To publish version 0.1.0 of your new logstash gem: + +```sh +bundle install +bundle exec rake vendor +bundle exec rspec +bundle exec rake publish_gem +``` + +::::{note} +Executing `rake publish_gem`: + +1. Reads the version from the gemspec file (`s.version = '0.1.0'`) +2. Checks in your local repository if a tag exists for that version. If the tag already exists, it aborts the process. Otherwise, it creates a new version tag in your local repository. +3. Builds the gem +4. Publishes the gem to RubyGems.org + +:::: + + +That’s it! Your plugin is published! Logstash users can now install your plugin by running: + +```sh +bin/logstash-plugin install logstash-input-mypluginname +``` + + + +## Contributing your source code to [logstash-plugins](https://github.com/logstash-plugins) [_contributing_your_source_code_to_logstash_pluginshttpsgithub_comlogstash_plugins] + +It is not required to contribute your source code to [logstash-plugins](https://github.com/logstash-plugins) github organization, but we always welcome new plugins! + +### Benefits [_benefits] + +Some of the many benefits of having your plugin in the logstash-plugins repository are: + +* **Discovery.** Your plugin will appear in the [Logstash Reference](/reference/index.md), where Logstash users look first for plugins and documentation. +* **Documentation.** Your plugin documentation will automatically be added to the [Logstash Reference](/reference/index.md). +* **Testing.** With our testing infrastructure, your plugin will be continuously tested against current and future releases of Logstash. As a result, users will have the assurance that if incompatibilities arise, they will be quickly discovered and corrected. + + +### Acceptance Guidelines [_acceptance_guidelines] + +* **Code Review.** Your plugin must be reviewed by members of the community for coherence, quality, readability, stability and security. +* **Tests.** Your plugin must contain tests to be accepted. These tests are also subject to code review for scope and completeness. It’s ok if you don’t know how to write tests — we will guide you. We are working on publishing a guide to creating tests for Logstash which will make it easier. In the meantime, you can refer to [http://betterspecs.org/](http://betterspecs.org/) for examples. + +To begin migrating your plugin to logstash-plugins, simply create a new [issue](https://github.com/elasticsearch/logstash/issues) in the Logstash repository. When the acceptance guidelines are completed, we will facilitate the move to the logstash-plugins organization using the recommended [github process](https://help.github.com/articles/transferring-a-repository/#transferring-from-a-user-to-an-organization). diff --git a/docs/extend/java-codec-plugin.md b/docs/extend/java-codec-plugin.md new file mode 100644 index 000000000..75c0562ed --- /dev/null +++ b/docs/extend/java-codec-plugin.md @@ -0,0 +1,348 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/java-codec-plugin.html +--- + +# How to write a Java codec plugin [java-codec-plugin] + +::::{note} +Java codecs are currently supported only for Java input and output plugins. They will not work with Ruby input or output plugins. +:::: + + +To develop a new Java codec for Logstash, you write a new Java class that conforms to the Logstash Java Codecs API, package it, and install it with the logstash-plugin utility. We’ll go through each of those steps. + + +## Set up your environment [_set_up_your_environment_2] + + +### Copy the example repo [_copy_the_example_repo_2] + +Start by copying the [example codec plugin](https://github.com/logstash-plugins/logstash-codec-java_codec_example). The plugin API is currently part of the Logstash codebase so you must have a local copy of that available. You can obtain a copy of the Logstash codebase with the following `git` command: + +```shell +git clone --branch --single-branch https://github.com/elastic/logstash.git +``` + +The `branch_name` should correspond to the version of Logstash containing the preferred revision of the Java plugin API. + +::::{note} +The GA version of the Java plugin API is available in the `7.2` and later branches of the Logstash codebase. +:::: + + +Specify the `target_folder` for your local copy of the Logstash codebase. If you do not specify `target_folder`, it defaults to a new folder called `logstash` under your current folder. + + +### Generate the .jar file [_generate_the_jar_file_2] + +After you have obtained a copy of the appropriate revision of the Logstash codebase, you need to compile it to generate the .jar file containing the Java plugin API. From the root directory of your Logstash codebase ($LS_HOME), you can compile it with `./gradlew assemble` (or `gradlew.bat assemble` if you’re running on Windows). This should produce the `$LS_HOME/logstash-core/build/libs/logstash-core-x.y.z.jar` where `x`, `y`, and `z` refer to the version of Logstash. + +After you have successfully compiled Logstash, you need to tell your Java plugin where to find the `logstash-core-x.y.z.jar` file. Create a new file named `gradle.properties` in the root folder of your plugin project. That file should have a single line: + +```txt +LOGSTASH_CORE_PATH=/logstash-core +``` + +where `target_folder` is the root folder of your local copy of the Logstash codebase. + + +## Code the plugin [_code_the_plugin_2] + +The example codec plugin decodes messages separated by a configurable delimiter and encodes messages by writing their string representation separated by a delimiter. For example, if the codec were configured with `/` as the delimiter, the input text `event1/event2/` would be decoded into two separate events with `message` fields of `event1` and `event2`, respectively. Note that this is only an example codec and does not cover all the edge cases that a production-grade codec should cover. + +Let’s look at the main class in that codec filter: + +```java +@LogstashPlugin(name="java_codec_example") +public class JavaCodecExample implements Codec { + + public static final PluginConfigSpec DELIMITER_CONFIG = + PluginConfigSpec.stringSetting("delimiter", ","); + + private final String id; + private final String delimiter; + + public JavaCodecExample(final Configuration config, final Context context) { + this(config.get(DELIMITER_CONFIG)); + } + + private JavaCodecExample(String delimiter) { + this.id = UUID.randomUUID().toString(); + this.delimiter = delimiter; + } + + @Override + public void decode(ByteBuffer byteBuffer, Consumer> consumer) { + // a not-production-grade delimiter decoder + byte[] byteInput = new byte[byteBuffer.remaining()]; + byteBuffer.get(byteInput); + if (byteInput.length > 0) { + String input = new String(byteInput); + String[] split = input.split(delimiter); + for (String s : split) { + Map map = new HashMap<>(); + map.put("message", s); + consumer.accept(map); + } + } + } + + @Override + public void flush(ByteBuffer byteBuffer, Consumer> consumer) { + // if the codec maintains any internal state such as partially-decoded input, this + // method should flush that state along with any additional input supplied in + // the ByteBuffer + + decode(byteBuffer, consumer); // this is a simplistic implementation + } + + @Override + public void encode(Event event, OutputStream outputStream) throws IOException { + outputStream.write((event.toString() + delimiter).getBytes(Charset.defaultCharset())); + } + + @Override + public Collection> configSchema() { + // should return a list of all configuration options for this plugin + return Collections.singletonList(DELIMITER_CONFIG); + } + + @Override + public Codec cloneCodec() { + return new JavaCodecExample(this.delimiter); + } + + @Override + public String getId() { + return this.id; + } + +} +``` + +Let’s step through and examine each part of that class. + + +### Class declaration [_class_declaration_6] + +```java +@LogstashPlugin(name="java_codec_example") +public class JavaCodecExample implements Codec { +``` + +Notes about the class declaration: + +* All Java plugins must be annotated with the `@LogstashPlugin` annotation. Additionally: + + * The `name` property of the annotation must be supplied and defines the name of the plugin as it will be used in the Logstash pipeline definition. For example, this codec would be referenced in the codec section of the an appropriate input or output in the Logstash pipeline defintion as `codec => java_codec_example { }` + * The value of the `name` property must match the name of the class excluding casing and underscores. + +* The class must implement the `co.elastic.logstash.api.Codec` interface. +* Java plugins may not be created in the `org.logstash` or `co.elastic.logstash` packages to prevent potential clashes with classes in Logstash itself. + + +#### Plugin settings [_plugin_settings_2] + +The snippet below contains both the setting definition and the method referencing it: + +```java +public static final PluginConfigSpec DELIMITER_CONFIG = + PluginConfigSpec.stringSetting("delimiter", ","); + +@Override +public Collection> configSchema() { + return Collections.singletonList(DELIMITER_CONFIG); +} +``` + +The `PluginConfigSpec` class allows developers to specify the settings that a plugin supports complete with setting name, data type, deprecation status, required status, and default value. In this example, the `delimiter` setting defines the delimiter on which the codec will split events. It is not a required setting and if it is not explicitly set, its default value will be `,`. + +The `configSchema` method must return a list of all settings that the plugin supports. The Logstash execution engine will validate that all required settings are present and that no unsupported settings are present. + + +#### Constructor and initialization [_constructor_and_initialization_2] + +```java +private final String id; +private final String delimiter; + +public JavaCodecExample(final Configuration config, final Context context) { + this(config.get(DELIMITER_CONFIG)); +} + +private JavaCodecExample(String delimiter) { + this.id = UUID.randomUUID().toString(); + this.delimiter = delimiter; +} +``` + +All Java codec plugins must have a constructor taking a `Configuration` and `Context` argument. This is the constructor that will be used to instantiate them at runtime. The retrieval and validation of all plugin settings should occur in this constructor. In this example, the delimiter to be used for delimiting events is retrieved from its setting and stored in a local variable so that it can be used later in the `decode` and `encode` methods. The codec’s ID is initialized to a random UUID (as should be done for most codecs), and a local `encoder` variable is initialized to encode and decode with a specified character set. + +Any additional initialization may occur in the constructor as well. If there are any unrecoverable errors encountered in the configuration or initialization of the codec plugin, a descriptive exception should be thrown. The exception will be logged and will prevent Logstash from starting. + + +### Codec methods [_codec_methods] + +```java +@Override +public void decode(ByteBuffer byteBuffer, Consumer> consumer) { + // a not-production-grade delimiter decoder + byte[] byteInput = new byte[byteBuffer.remaining()]; + byteBuffer.get(byteInput); + if (byteInput.length > 0) { + String input = new String(byteInput); + String[] split = input.split(delimiter); + for (String s : split) { + Map map = new HashMap<>(); + map.put("message", s); + consumer.accept(map); + } + } +} + +@Override +public void flush(ByteBuffer byteBuffer, Consumer> consumer) { + // if the codec maintains any internal state such as partially-decoded input, this + // method should flush that state along with any additional input supplied in + // the ByteBuffer + + decode(byteBuffer, consumer); // this is a simplistic implementation +} + +@Override +public void encode(Event event, OutputStream outputStream) throws IOException { + outputStream.write((event.toString() + delimiter).getBytes(Charset.defaultCharset())); +} +``` + +The `decode`, `flush`, and `encode` methods provide the core functionality of the codec. Codecs may be used by inputs to decode a sequence or stream of bytes into events or by outputs to encode events into a sequence of bytes. + +The `decode` method decodes events from the specified `ByteBuffer` and passes them to the provided `Consumer`. The input must provide a `ByteBuffer` that is ready for reading with `byteBuffer.position()` indicating the next position to read and `byteBuffer.limit()` indicating the first byte in the buffer that is not safe to read. Codecs must ensure that `byteBuffer.position()` reflects the last-read position before returning control to the input. The input is then responsible for returning the buffer to write mode via either `byteBuffer.clear()` or `byteBuffer.compact()` before resuming writes. In the example above, the `decode` method simply splits the incoming byte stream on the specified delimiter. A production-grade codec such as [`java-line`](https://github.com/elastic/logstash/blob/main/logstash-core/src/main/java/org/logstash/plugins/codecs/Line.java) would not make the simplifying assumption that the end of the supplied byte stream corresponded with the end of an event. + +Events should be constructed as instances of `Map` and pushed into the event pipeline via the `Consumer>.accept()` method. To reduce allocations and GC pressure, codecs may reuse the same map instance by modifying its fields between calls to `Consumer>.accept()` because the event pipeline will create events based on a copy of the map’s data. + +The `flush` method works in coordination with the `decode` method to decode all remaining events from the specified `ByteBuffer` along with any internal state that may remain after previous calls to the `decode` method. As an example of internal state that a codec might maintain, consider an input stream of bytes `event1/event2/event3` with a delimiter of `/`. Due to buffering or other reasons, the input might supply a partial stream of bytes such as `event1/eve` to the codec’s `decode` method. In this case, the codec could save the beginning three characters `eve` of the second event rather than assuming that the supplied byte stream ends on an event boundary. If the next call to `decode` supplied the `nt2/ev` bytes, the codec would prepend the saved `eve` bytes to produce the full `event2` event and then save the remaining `ev` bytes for decoding when the remainder of the bytes for that event were supplied. A call to `flush` signals the codec that the supplied bytes represent the end of an event stream and all remaining bytes should be decoded to events. The `flush` example above is a simplistic implementation that does not maintain any state about partially-supplied byte streams across calls to `decode`. + +The `encode` method encodes an event into a sequence of bytes and writes it into the specified `OutputStream`. Because a single codec instance is shared across all pipeline workers in the output stage of the Logstash pipeline, codecs should *not* retain state across calls to their `encode` methods. + + +### cloneCodec method [_clonecodec_method] + +```java +@Override +public Codec cloneCodec() { + return new JavaCodecExample(this.delimiter); +} +``` + +The `cloneCodec` method should return an identical instance of the codec with the exception of its ID. Because codecs may be stateful across calls to their `decode` methods, input plugins that are multi-threaded should use a separate instance of each codec via the `cloneCodec` method for each of their threads. Because a single codec instance is shared across all pipeline workers in the output stage of the Logstash pipeline, codecs should *not* retain state across calls to their `encode` methods. In the example above, the codec is cloned with the same delimiter but a different ID. + + +### getId method [_getid_method_2] + +```java +@Override +public String getId() { + return id; +} +``` + +For codec plugins, the `getId` method should always return the id that was set at instantiation time. This is typically an UUID. + + +### Unit tests [_unit_tests_2] + +Lastly, but certainly not least importantly, unit tests are strongly encouraged. The example codec plugin includes an [example unit test](https://github.com/logstash-plugins/logstash-codec-java_codec_example/blob/main/src/test/java/org/logstashplugins/JavaCodecExampleTest.java) that you can use as a template for your own. + + +## Package and deploy [_package_and_deploy_2] + +Java plugins are packaged as Ruby gems for dependency management and interoperability with Ruby plugins. Once they are packaged as gems, they may be installed with the `logstash-plugin` utility just as Ruby plugins are. Because no knowledge of Ruby or its toolchain should be required for Java plugin development, the procedure for packaging Java plugins as Ruby gems has been automated through a custom task in the Gradle build file provided with the example Java plugins. The following sections describe how to configure and execute that packaging task as well as how to install the packaged Java plugin in Logstash. + + +### Configuring the Gradle packaging task [_configuring_the_gradle_packaging_task_2] + +The following section appears near the top of the `build.gradle` file supplied with the example Java plugins: + +```java +// =========================================================================== +// plugin info +// =========================================================================== +group 'org.logstashplugins' // must match the package of the main plugin class +version "${file("VERSION").text.trim()}" // read from required VERSION file +description = "Example Java filter implementation" +pluginInfo.licenses = ['Apache-2.0'] // list of SPDX license IDs +pluginInfo.longDescription = "This gem is a Logstash plugin required to be installed on top of the Logstash core pipeline using \$LS_HOME/bin/logstash-plugin install gemname. This gem is not a stand-alone program" +pluginInfo.authors = ['Elasticsearch'] +pluginInfo.email = ['info@elastic.co'] +pluginInfo.homepage = "http://www.elastic.co/guide/en/logstash/current/index.html" +pluginInfo.pluginType = "filter" +pluginInfo.pluginClass = "JavaFilterExample" +pluginInfo.pluginName = "java_filter_example" +// =========================================================================== +``` + +You should configure the values above for your plugin. + +* The `version` value will be automatically read from the `VERSION` file in the root of your plugin’s codebase. +* `pluginInfo.pluginType` should be set to one of `input`, `filter`, `codec`, or `output`. +* `pluginInfo.pluginName` must match the name specified on the `@LogstashPlugin` annotation on the main plugin class. The Gradle packaging task will validate that and return an error if they do not match. + + +### Running the Gradle packaging task [_running_the_gradle_packaging_task_2] + +Several Ruby source files along with a `gemspec` file and a `Gemfile` are required to package the plugin as a Ruby gem. These Ruby files are used only for defining the Ruby gem structure or at Logstash startup time to register the Java plugin. They are not used during runtime event processing. The Gradle packaging task automatically generates all of these files based on the values configured in the section above. + +You run the Gradle packaging task with the following command: + +```shell +./gradlew gem +``` + +For Windows platforms: Substitute `gradlew.bat` for `./gradlew` as appropriate in the command. + +That task will produce a gem file in the root directory of your plugin’s codebase with the name `logstash-{{plugintype}}--.gem` + + +### Installing the Java plugin in Logstash [_installing_the_java_plugin_in_logstash_2] + +After you have packaged your Java plugin as a Ruby gem, you can install it in Logstash with this command: + +```shell +bin/logstash-plugin install --no-verify --local /path/to/javaPlugin.gem +``` + +For Windows platforms: Substitute backslashes for forward slashes as appropriate in the command. + + +## Run Logstash with the Java codec plugin [_run_logstash_with_the_java_codec_plugin] + +To test the plugin, start Logstash with: + +```java +echo "foo,bar" | bin/logstash -e 'input { java_stdin { codec => java_codec_example } }' +``` + +The expected Logstash output (excluding initialization) with the configuration above is: + +```txt +{ + "@version" => "1", + "message" => "foo", + "@timestamp" => yyyy-MM-ddThh:mm:ss.SSSZ, + "host" => "" +} +{ + "@version" => "1", + "message" => "bar\n", + "@timestamp" => yyyy-MM-ddThh:mm:ss.SSSZ, + "host" => "" +} +``` + + +## Feedback [_feedback_2] + +If you have any feedback on Java plugin support in Logstash, please comment on our [main Github issue](https://github.com/elastic/logstash/issues/9215) or post in the [Logstash forum](https://discuss.elastic.co/c/logstash). + diff --git a/docs/extend/java-filter-plugin.md b/docs/extend/java-filter-plugin.md new file mode 100644 index 000000000..bc7aba01c --- /dev/null +++ b/docs/extend/java-filter-plugin.md @@ -0,0 +1,307 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/java-filter-plugin.html +--- + +# How to write a Java filter plugin [java-filter-plugin] + +To develop a new Java filter for Logstash, you write a new Java class that conforms to the Logstash Java Filters API, package it, and install it with the logstash-plugin utility. We’ll go through each of those steps. + + +## Set up your environment [_set_up_your_environment_3] + + +### Copy the example repo [_copy_the_example_repo_3] + +Start by copying the [example filter plugin](https://github.com/logstash-plugins/logstash-filter-java_filter_example). The plugin API is currently part of the Logstash codebase so you must have a local copy of that available. You can obtain a copy of the Logstash codebase with the following `git` command: + +```shell +git clone --branch --single-branch https://github.com/elastic/logstash.git +``` + +The `branch_name` should correspond to the version of Logstash containing the preferred revision of the Java plugin API. + +::::{note} +The GA version of the Java plugin API is available in the `7.2` and later branches of the Logstash codebase. +:::: + + +Specify the `target_folder` for your local copy of the Logstash codebase. If you do not specify `target_folder`, it defaults to a new folder called `logstash` under your current folder. + + +### Generate the .jar file [_generate_the_jar_file_3] + +After you have obtained a copy of the appropriate revision of the Logstash codebase, you need to compile it to generate the .jar file containing the Java plugin API. From the root directory of your Logstash codebase ($LS_HOME), you can compile it with `./gradlew assemble` (or `gradlew.bat assemble` if you’re running on Windows). This should produce the `$LS_HOME/logstash-core/build/libs/logstash-core-x.y.z.jar` where `x`, `y`, and `z` refer to the version of Logstash. + +After you have successfully compiled Logstash, you need to tell your Java plugin where to find the `logstash-core-x.y.z.jar` file. Create a new file named `gradle.properties` in the root folder of your plugin project. That file should have a single line: + +```txt +LOGSTASH_CORE_PATH=/logstash-core +``` + +where `target_folder` is the root folder of your local copy of the Logstash codebase. + + +## Code the plugin [_code_the_plugin_3] + +The example filter plugin allows one to configure a field in each event that will be reversed. For example, if the filter were configured to reverse the `day_of_week` field, an event with `day_of_week: "Monday"` would be transformed to `day_of_week: "yadnoM"`. Let’s look at the main class in that example filter: + +```java +@LogstashPlugin(name = "java_filter_example") +public class JavaFilterExample implements Filter { + + public static final PluginConfigSpec SOURCE_CONFIG = + PluginConfigSpec.stringSetting("source", "message"); + + private String id; + private String sourceField; + + public JavaFilterExample(String id, Configuration config, Context context) { + this.id = id; + this.sourceField = config.get(SOURCE_CONFIG); + } + + @Override + public Collection filter(Collection events, FilterMatchListener matchListener) { + for (Event e : events) { + Object f = e.getField(sourceField); + if (f instanceof String) { + e.setField(sourceField, StringUtils.reverse((String)f)); + matchListener.filterMatched(e); + } + } + return events; + } + + @Override + public Collection> configSchema() { + return Collections.singletonList(SOURCE_CONFIG); + } + + @Override + public String getId() { + return this.id; + } + + @Override + public void close() { + this.sourceField = null; + return; + } +} +``` + +Let’s step through and examine each part of that class. + + +### Class declaration [_class_declaration_7] + +```java +@LogstashPlugin(name = "java_filter_example") +public class JavaFilterExample implements Filter { +``` + +Notes about the class declaration: + +* All Java plugins must be annotated with the `@LogstashPlugin` annotation. Additionally: + + * The `name` property of the annotation must be supplied and defines the name of the plugin as it will be used in the Logstash pipeline definition. For example, this filter would be referenced in the filter section of the Logstash pipeline defintion as `filter { java_filter_example => { .... } }` + * The value of the `name` property must match the name of the class excluding casing and underscores. + +* The class must implement the `co.elastic.logstash.api.Filter` interface. +* Java plugins may not be created in the `org.logstash` or `co.elastic.logstash` packages to prevent potential clashes with classes in Logstash itself. + + +### Plugin settings [_plugin_settings_3] + +The snippet below contains both the setting definition and the method referencing it: + +```java +public static final PluginConfigSpec SOURCE_CONFIG = + PluginConfigSpec.stringSetting("source", "message"); + +@Override +public Collection> configSchema() { + return Collections.singletonList(SOURCE_CONFIG); +} +``` + +The `PluginConfigSpec` class allows developers to specify the settings that a plugin supports complete with setting name, data type, deprecation status, required status, and default value. In this example, the `source` setting defines the name of the field in each event that will be reversed. It is not a required setting and if it is not explicitly set, its default value will be `message`. + +The `configSchema` method must return a list of all settings that the plugin supports. In a future phase of the Java plugin project, the Logstash execution engine will validate that all required settings are present and that no unsupported settings are present. + + +### Constructor and initialization [_constructor_and_initialization_3] + +```java +private String id; +private String sourceField; + +public JavaFilterExample(String id, Configuration config, Context context) { + this.id = id; + this.sourceField = config.get(SOURCE_CONFIG); +} +``` + +All Java filter plugins must have a constructor taking a `String` id and a `Configuration` and `Context` argument. This is the constructor that will be used to instantiate them at runtime. The retrieval and validation of all plugin settings should occur in this constructor. In this example, the name of the field to be reversed in each event is retrieved from its setting and stored in a local variable so that it can be used later in the `filter` method. + +Any additional initialization may occur in the constructor as well. If there are any unrecoverable errors encountered in the configuration or initialization of the filter plugin, a descriptive exception should be thrown. The exception will be logged and will prevent Logstash from starting. + + +### Filter method [_filter_method_2] + +```java +@Override +public Collection filter(Collection events, FilterMatchListener matchListener) { + for (Event e : events) { + Object f = e.getField(sourceField); + if (f instanceof String) { + e.setField(sourceField, StringUtils.reverse((String)f)); + matchListener.filterMatched(e); + } + } + return events; +``` + +Finally, we come to the `filter` method that is invoked by the Logstash execution engine on batches of events as they flow through the event processing pipeline. The events to be filtered are supplied in the `events` argument and the method should return a collection of filtered events. Filters may perform a variety of actions on events as they flow through the pipeline including: + +* Mutation — Fields in events may be added, removed, or changed by a filter. This is the most common scenario for filters that perform various kinds of enrichment on events. In this scenario, the incoming `events` collection may be returned unmodified since the events in the collection are mutated in place. +* Deletion — Events may be removed from the event pipeline by a filter so that subsequent filters and outputs do not receive them. In this scenario, the events to be deleted must be removed from the collection of filtered events before it is returned. +* Creation — A filter may insert new events into the event pipeline that will be seen only by subsequent filters and outputs. In this scenario, the new events must be added to the collection of filtered events before it is returned. +* Observation — Events may pass unchanged by a filter through the event pipeline. This may be useful in scenarios where a filter performs external actions (e.g., updating an external cache) based on the events observed in the event pipeline. In this scenario, the incoming `events` collection may be returned unmodified since no changes were made. + +In the example above, the value of the `source` field is retrieved from each event and reversed if it is a string value. Because each event is mutated in place, the incoming `events` collection can be returned. + +The `matchListener` is the mechanism by which filters indicate which events "match". The common actions for filters such as `add_field` and `add_tag` are applied only to events that are designated as "matching". Some filters such as the [grok filter](/reference/plugins-filters-grok.md) have a clear definition for what constitutes a matching event and will notify the listener only for matching events. Other filters such as the [UUID filter](/reference/plugins-filters-uuid.md) have no specific match criteria and should notify the listener for every event filtered. In this example, the filter notifies the match listener for any event that had a `String` value in its `source` field and was therefore able to be reversed. + + +### getId method [_getid_method_3] + +```java +@Override +public String getId() { + return id; +} +``` + +For filter plugins, the `getId` method should always return the id that was provided to the plugin through its constructor at instantiation time. + + +### close method [_close_method] + +```java +@Override +public void close() { + // shutdown a resource that was instantiated during the filter initialization phase. + this.sourceField = null; + return; +} +``` + +Filter plugins can use additional resources to perform operations, such as creating new database connections. Implementing the `close` method will allow the plugins to free up those resources when shutting down the pipeline. + + +### Unit tests [_unit_tests_3] + +Lastly, but certainly not least importantly, unit tests are strongly encouraged. The example filter plugin includes an [example unit test](https://github.com/logstash-plugins/logstash-filter-java_filter_example/blob/main/src/test/java/org/logstashplugins/JavaFilterExampleTest.java) that you can use as a template for your own. + + +## Package and deploy [_package_and_deploy_3] + +Java plugins are packaged as Ruby gems for dependency management and interoperability with Ruby plugins. Once they are packaged as gems, they may be installed with the `logstash-plugin` utility just as Ruby plugins are. Because no knowledge of Ruby or its toolchain should be required for Java plugin development, the procedure for packaging Java plugins as Ruby gems has been automated through a custom task in the Gradle build file provided with the example Java plugins. The following sections describe how to configure and execute that packaging task as well as how to install the packaged Java plugin in Logstash. + + +### Configuring the Gradle packaging task [_configuring_the_gradle_packaging_task_3] + +The following section appears near the top of the `build.gradle` file supplied with the example Java plugins: + +```java +// =========================================================================== +// plugin info +// =========================================================================== +group 'org.logstashplugins' // must match the package of the main plugin class +version "${file("VERSION").text.trim()}" // read from required VERSION file +description = "Example Java filter implementation" +pluginInfo.licenses = ['Apache-2.0'] // list of SPDX license IDs +pluginInfo.longDescription = "This gem is a Logstash plugin required to be installed on top of the Logstash core pipeline using \$LS_HOME/bin/logstash-plugin install gemname. This gem is not a stand-alone program" +pluginInfo.authors = ['Elasticsearch'] +pluginInfo.email = ['info@elastic.co'] +pluginInfo.homepage = "http://www.elastic.co/guide/en/logstash/current/index.html" +pluginInfo.pluginType = "filter" +pluginInfo.pluginClass = "JavaFilterExample" +pluginInfo.pluginName = "java_filter_example" +// =========================================================================== +``` + +You should configure the values above for your plugin. + +* The `version` value will be automatically read from the `VERSION` file in the root of your plugin’s codebase. +* `pluginInfo.pluginType` should be set to one of `input`, `filter`, `codec`, or `output`. +* `pluginInfo.pluginName` must match the name specified on the `@LogstashPlugin` annotation on the main plugin class. The Gradle packaging task will validate that and return an error if they do not match. + + +### Running the Gradle packaging task [_running_the_gradle_packaging_task_3] + +Several Ruby source files along with a `gemspec` file and a `Gemfile` are required to package the plugin as a Ruby gem. These Ruby files are used only for defining the Ruby gem structure or at Logstash startup time to register the Java plugin. They are not used during runtime event processing. The Gradle packaging task automatically generates all of these files based on the values configured in the section above. + +You run the Gradle packaging task with the following command: + +```shell +./gradlew gem +``` + +For Windows platforms: Substitute `gradlew.bat` for `./gradlew` as appropriate in the command. + +That task will produce a gem file in the root directory of your plugin’s codebase with the name `logstash-{{plugintype}}--.gem` + + +### Installing the Java plugin in Logstash [_installing_the_java_plugin_in_logstash_3] + +After you have packaged your Java plugin as a Ruby gem, you can install it in Logstash with this command: + +```shell +bin/logstash-plugin install --no-verify --local /path/to/javaPlugin.gem +``` + +For Windows platforms: Substitute backslashes for forward slashes as appropriate in the command. + + +## Run Logstash with the Java filter plugin [_run_logstash_with_the_java_filter_plugin] + +The following is a minimal Logstash configuration that can be used to test that the Java filter plugin is correctly installed and functioning. + +```java +input { + generator { message => "Hello world!" count => 1 } +} +filter { + java_filter_example {} +} +output { + stdout { codec => rubydebug } +} +``` + +Copy the above Logstash configuration to a file such as `java_filter.conf`. Start Logstash with: + +```shell +bin/logstash -f /path/to/java_filter.conf +``` + +The expected Logstash output (excluding initialization) with the configuration above is: + +```txt +{ + "sequence" => 0, + "@version" => "1", + "message" => "!dlrow olleH", + "@timestamp" => yyyy-MM-ddThh:mm:ss.SSSZ, + "host" => "" +} +``` + + +## Feedback [_feedback_3] + +If you have any feedback on Java plugin support in Logstash, please comment on our [main Github issue](https://github.com/elastic/logstash/issues/9215) or post in the [Logstash forum](https://discuss.elastic.co/c/logstash). + diff --git a/docs/extend/java-input-plugin.md b/docs/extend/java-input-plugin.md new file mode 100644 index 000000000..240a1be9e --- /dev/null +++ b/docs/extend/java-input-plugin.md @@ -0,0 +1,341 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/java-input-plugin.html +--- + +# How to write a Java input plugin [java-input-plugin] + +To develop a new Java input for Logstash, you write a new Java class that conforms to the Logstash Java Inputs API, package it, and install it with the logstash-plugin utility. We’ll go through each of those steps. + + +## Set up your environment [_set_up_your_environment] + + +### Copy the example repo [_copy_the_example_repo] + +Start by copying the [example input plugin](https://github.com/logstash-plugins/logstash-input-java_input_example). The plugin API is currently part of the Logstash codebase so you must have a local copy of that available. You can obtain a copy of the Logstash codebase with the following `git` command: + +```shell +git clone --branch --single-branch https://github.com/elastic/logstash.git +``` + +The `branch_name` should correspond to the version of Logstash containing the preferred revision of the Java plugin API. + +::::{note} +The GA version of the Java plugin API is available in the `7.2` and later branches of the Logstash codebase. +:::: + + +Specify the `target_folder` for your local copy of the Logstash codebase. If you do not specify `target_folder`, it defaults to a new folder called `logstash` under your current folder. + + +### Generate the .jar file [_generate_the_jar_file] + +After you have obtained a copy of the appropriate revision of the Logstash codebase, you need to compile it to generate the .jar file containing the Java plugin API. From the root directory of your Logstash codebase ($LS_HOME), you can compile it with `./gradlew assemble` (or `gradlew.bat assemble` if you’re running on Windows). This should produce the `$LS_HOME/logstash-core/build/libs/logstash-core-x.y.z.jar` where `x`, `y`, and `z` refer to the version of Logstash. + +After you have successfully compiled Logstash, you need to tell your Java plugin where to find the `logstash-core-x.y.z.jar` file. Create a new file named `gradle.properties` in the root folder of your plugin project. That file should have a single line: + +```txt +LOGSTASH_CORE_PATH=/logstash-core +``` + +where `target_folder` is the root folder of your local copy of the Logstash codebase. + + +## Code the plugin [_code_the_plugin] + +The example input plugin generates a configurable number of simple events before terminating. Let’s look at the main class in the example input. + +```java +@LogstashPlugin(name="java_input_example") +public class JavaInputExample implements Input { + + public static final PluginConfigSpec EVENT_COUNT_CONFIG = + PluginConfigSpec.numSetting("count", 3); + + public static final PluginConfigSpec PREFIX_CONFIG = + PluginConfigSpec.stringSetting("prefix", "message"); + + private String id; + private long count; + private String prefix; + private final CountDownLatch done = new CountDownLatch(1); + private volatile boolean stopped; + + + public JavaInputExample(String id, Configuration config, Context context) { + this.id = id; + count = config.get(EVENT_COUNT_CONFIG); + prefix = config.get(PREFIX_CONFIG); + } + + @Override + public void start(Consumer> consumer) { + int eventCount = 0; + try { + while (!stopped && eventCount < count) { + eventCount++; + consumer.accept.push(Collections.singletonMap("message", + prefix + " " + StringUtils.center(eventCount + " of " + count, 20))); + } + } finally { + stopped = true; + done.countDown(); + } + } + + @Override + public void stop() { + stopped = true; // set flag to request cooperative stop of input + } + + @Override + public void awaitStop() throws InterruptedException { + done.await(); // blocks until input has stopped + } + + @Override + public Collection> configSchema() { + return Arrays.asList(EVENT_COUNT_CONFIG, PREFIX_CONFIG); + } + + @Override + public String getId() { + return this.id; + } +} +``` + +Let’s step through and examine each part of that class. + + +### Class declaration [_class_declaration_5] + +```java +@LogstashPlugin(name="java_input_example") +public class JavaInputExample implements Input { +``` + +Notes about the class declaration: + +* All Java plugins must be annotated with the `@LogstashPlugin` annotation. Additionally: + + * The `name` property of the annotation must be supplied and defines the name of the plugin as it will be used in the Logstash pipeline definition. For example, this input would be referenced in the input section of the Logstash pipeline defintion as `input { java_input_example => { .... } }` + * The value of the `name` property must match the name of the class excluding casing and underscores. + +* The class must implement the `co.elastic.logstash.api.Input` interface. +* Java plugins may not be created in the `org.logstash` or `co.elastic.logstash` packages to prevent potential clashes with classes in Logstash itself. + + +### Plugin settings [_plugin_settings] + +The snippet below contains both the setting definition and the method referencing it. + +```java +public static final PluginConfigSpec EVENT_COUNT_CONFIG = + PluginConfigSpec.numSetting("count", 3); + +public static final PluginConfigSpec PREFIX_CONFIG = + PluginConfigSpec.stringSetting("prefix", "message"); + +@Override +public Collection> configSchema() { + return Arrays.asList(EVENT_COUNT_CONFIG, PREFIX_CONFIG); +} +``` + +The `PluginConfigSpec` class allows developers to specify the settings that a plugin supports complete with setting name, data type, deprecation status, required status, and default value. In this example, the `count` setting defines the number of events that will be generated and the `prefix` setting defines an optional prefix to include in the event field. Neither setting is required and if it is not explicitly set, the settings default to `3` and `message`, respectively. + +The `configSchema` method must return a list of all settings that the plugin supports. In a future phase of the Java plugin project, the Logstash execution engine will validate that all required settings are present and that no unsupported settings are present. + + +### Constructor and initialization [_constructor_and_initialization] + +```java +private String id; +private long count; +private String prefix; + +public JavaInputExample(String id, Configuration config, Context context) { + this.id = id; + count = config.get(EVENT_COUNT_CONFIG); + prefix = config.get(PREFIX_CONFIG); +} +``` + +All Java input plugins must have a constructor taking a `String` id and `Configuration` and `Context` argument. This is the constructor that will be used to instantiate them at runtime. The retrieval and validation of all plugin settings should occur in this constructor. In this example, the values of the two plugin settings are retrieved and stored in local variables for later use in the `start` method. + +Any additional initialization may occur in the constructor as well. If there are any unrecoverable errors encountered in the configuration or initialization of the input plugin, a descriptive exception should be thrown. The exception will be logged and will prevent Logstash from starting. + + +### Start method [_start_method] + +```java +@Override +public void start(Consumer> consumer) { + int eventCount = 0; + try { + while (!stopped && eventCount < count) { + eventCount++; + consumer.accept.push(Collections.singletonMap("message", + prefix + " " + StringUtils.center(eventCount + " of " + count, 20))); + } + } finally { + stopped = true; + done.countDown(); + } +} +``` + +The `start` method begins the event-producing loop in an input. Inputs are flexible and may produce events through many different mechanisms including: + +* a pull mechanism such as periodic queries of external database +* a push mechanism such as events sent from clients to a local network port +* a timed computation such as a heartbeat +* any other mechanism that produces a useful stream of events. Event streams may be either finite or infinite. If the input produces an infinite stream of events, this method should loop until a stop request is made through the `stop` method. If the input produces a finite stream of events, this method should terminate when the last event in the stream is produced or a stop request is made, whichever comes first. + +Events should be constructed as instances of `Map` and pushed into the event pipeline via the `Consumer>.accept()` method. To reduce allocations and GC pressure, inputs may reuse the same map instance by modifying its fields between calls to `Consumer>.accept()` because the event pipeline will create events based on a copy of the map’s data. + + +### Stop and awaitStop methods [_stop_and_awaitstop_methods] + +```java +private final CountDownLatch done = new CountDownLatch(1); +private volatile boolean stopped; + +@Override +public void stop() { + stopped = true; // set flag to request cooperative stop of input +} + +@Override +public void awaitStop() throws InterruptedException { + done.await(); // blocks until input has stopped +} +``` + +The `stop` method notifies the input to stop producing events. The stop mechanism may be implemented in any way that honors the API contract though a `volatile boolean` flag works well for many use cases. + +Inputs stop both asynchronously and cooperatively. Use the `awaitStop` method to block until the input has completed the stop process. Note that this method should **not** signal the input to stop as the `stop` method does. The awaitStop mechanism may be implemented in any way that honors the API contract though a `CountDownLatch` works well for many use cases. + + +### getId method [_getid_method] + +```java +@Override +public String getId() { + return id; +} +``` + +For input plugins, the `getId` method should always return the id that was provided to the plugin through its constructor at instantiation time. + + +### Unit tests [_unit_tests] + +Lastly, but certainly not least importantly, unit tests are strongly encouraged. The example input plugin includes an [example unit test](https://github.com/logstash-plugins/logstash-input-java_input_example/blob/main/src/test/java/org/logstashplugins/JavaInputExampleTest.java) that you can use as a template for your own. + + +## Package and deploy [_package_and_deploy] + +Java plugins are packaged as Ruby gems for dependency management and interoperability with Ruby plugins. Once they are packaged as gems, they may be installed with the `logstash-plugin` utility just as Ruby plugins are. Because no knowledge of Ruby or its toolchain should be required for Java plugin development, the procedure for packaging Java plugins as Ruby gems has been automated through a custom task in the Gradle build file provided with the example Java plugins. The following sections describe how to configure and execute that packaging task as well as how to install the packaged Java plugin in Logstash. + + +### Configuring the Gradle packaging task [_configuring_the_gradle_packaging_task] + +The following section appears near the top of the `build.gradle` file supplied with the example Java plugins: + +```java +// =========================================================================== +// plugin info +// =========================================================================== +group 'org.logstashplugins' // must match the package of the main plugin class +version "${file("VERSION").text.trim()}" // read from required VERSION file +description = "Example Java filter implementation" +pluginInfo.licenses = ['Apache-2.0'] // list of SPDX license IDs +pluginInfo.longDescription = "This gem is a Logstash plugin required to be installed on top of the Logstash core pipeline using \$LS_HOME/bin/logstash-plugin install gemname. This gem is not a stand-alone program" +pluginInfo.authors = ['Elasticsearch'] +pluginInfo.email = ['info@elastic.co'] +pluginInfo.homepage = "http://www.elastic.co/guide/en/logstash/current/index.html" +pluginInfo.pluginType = "filter" +pluginInfo.pluginClass = "JavaFilterExample" +pluginInfo.pluginName = "java_filter_example" +// =========================================================================== +``` + +You should configure the values above for your plugin. + +* The `version` value will be automatically read from the `VERSION` file in the root of your plugin’s codebase. +* `pluginInfo.pluginType` should be set to one of `input`, `filter`, `codec`, or `output`. +* `pluginInfo.pluginName` must match the name specified on the `@LogstashPlugin` annotation on the main plugin class. The Gradle packaging task will validate that and return an error if they do not match. + + +### Running the Gradle packaging task [_running_the_gradle_packaging_task] + +Several Ruby source files along with a `gemspec` file and a `Gemfile` are required to package the plugin as a Ruby gem. These Ruby files are used only for defining the Ruby gem structure or at Logstash startup time to register the Java plugin. They are not used during runtime event processing. The Gradle packaging task automatically generates all of these files based on the values configured in the section above. + +You run the Gradle packaging task with the following command: + +```shell +./gradlew gem +``` + +For Windows platforms: Substitute `gradlew.bat` for `./gradlew` as appropriate in the command. + +That task will produce a gem file in the root directory of your plugin’s codebase with the name `logstash-{{plugintype}}--.gem` + + +### Installing the Java plugin in Logstash [_installing_the_java_plugin_in_logstash] + +After you have packaged your Java plugin as a Ruby gem, you can install it in Logstash with this command: + +```shell +bin/logstash-plugin install --no-verify --local /path/to/javaPlugin.gem +``` + +For Windows platforms: Substitute backslashes for forward slashes as appropriate in the command. + + +## Running Logstash with the Java input plugin [_running_logstash_with_the_java_input_plugin] + +The following is a minimal Logstash configuration that can be used to test that the Java input plugin is correctly installed and functioning. + +```java +input { + java_input_example {} +} +output { + stdout { codec => rubydebug } +} +``` + +Copy the above Logstash configuration to a file such as `java_input.conf`. Start {{ls}} with: + +```shell +bin/logstash -f /path/to/java_input.conf +``` + +The expected Logstash output (excluding initialization) with the configuration above is: + +```txt +{ + "@version" => "1", + "message" => "message 1 of 3 ", + "@timestamp" => yyyy-MM-ddThh:mm:ss.SSSZ +} +{ + "@version" => "1", + "message" => "message 2 of 3 ", + "@timestamp" => yyyy-MM-ddThh:mm:ss.SSSZ +} +{ + "@version" => "1", + "message" => "message 3 of 3 ", + "@timestamp" => yyyy-MM-ddThh:mm:ss.SSSZ +} +``` + + +## Feedback [_feedback] + +If you have any feedback on Java plugin support in Logstash, please comment on our [main Github issue](https://github.com/elastic/logstash/issues/9215) or post in the [Logstash forum](https://discuss.elastic.co/c/logstash). diff --git a/docs/extend/java-output-plugin.md b/docs/extend/java-output-plugin.md new file mode 100644 index 000000000..e8e7a6040 --- /dev/null +++ b/docs/extend/java-output-plugin.md @@ -0,0 +1,311 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/java-output-plugin.html +--- + +# How to write a Java output plugin [java-output-plugin] + +To develop a new Java output for Logstash, you write a new Java class that conforms to the Logstash Java Outputs API, package it, and install it with the logstash-plugin utility. We’ll go through each of those steps. + + +## Set up your environment [_set_up_your_environment_4] + + +### Copy the example repo [_copy_the_example_repo_4] + +Start by copying the [example output plugin](https://github.com/logstash-plugins/logstash-output-java_output_example). The plugin API is currently part of the Logstash codebase so you must have a local copy of that available. You can obtain a copy of the Logstash codebase with the following `git` command: + +```shell +git clone --branch --single-branch https://github.com/elastic/logstash.git +``` + +The `branch_name` should correspond to the version of Logstash containing the preferred revision of the Java plugin API. + +::::{note} +The GA version of the Java plugin API is available in the `7.2` and later branches of the Logstash codebase. +:::: + + +Specify the `target_folder` for your local copy of the Logstash codebase. If you do not specify `target_folder`, it defaults to a new folder called `logstash` under your current folder. + + +### Generate the .jar file [_generate_the_jar_file_4] + +After you have obtained a copy of the appropriate revision of the Logstash codebase, you need to compile it to generate the .jar file containing the Java plugin API. From the root directory of your Logstash codebase ($LS_HOME), you can compile it with `./gradlew assemble` (or `gradlew.bat assemble` if you’re running on Windows). This should produce the `$LS_HOME/logstash-core/build/libs/logstash-core-x.y.z.jar` where `x`, `y`, and `z` refer to the version of Logstash. + +After you have successfully compiled Logstash, you need to tell your Java plugin where to find the `logstash-core-x.y.z.jar` file. Create a new file named `gradle.properties` in the root folder of your plugin project. That file should have a single line: + +```txt +LOGSTASH_CORE_PATH=/logstash-core +``` + +where `target_folder` is the root folder of your local copy of the Logstash codebase. + + +## Code the plugin [_code_the_plugin_4] + +The example output plugin prints events to the console using the event’s `toString` method. Let’s look at the main class in the example output: + +```java +@LogstashPlugin(name = "java_output_example") +public class JavaOutputExample implements Output { + + public static final PluginConfigSpec PREFIX_CONFIG = + PluginConfigSpec.stringSetting("prefix", ""); + + private final String id; + private String prefix; + private PrintStream printer; + private final CountDownLatch done = new CountDownLatch(1); + private volatile boolean stopped = false; + + public JavaOutputExample(final String id, final Configuration configuration, final Context context) { + this(id, configuration, context, System.out); + } + + JavaOutputExample(final String id, final Configuration config, final Context context, OutputStream targetStream) { + this.id = id; + prefix = config.get(PREFIX_CONFIG); + printer = new PrintStream(targetStream); + } + + @Override + public void output(final Collection events) { + Iterator z = events.iterator(); + while (z.hasNext() && !stopped) { + String s = prefix + z.next(); + printer.println(s); + } + } + + @Override + public void stop() { + stopped = true; + done.countDown(); + } + + @Override + public void awaitStop() throws InterruptedException { + done.await(); + } + + @Override + public Collection> configSchema() { + return Collections.singletonList(PREFIX_CONFIG); + } + + @Override + public String getId() { + return id; + } +} +``` + +Let’s step through and examine each part of that class. + + +### Class declaration [_class_declaration_8] + +```java +@LogstashPlugin(name="java_output_example") +public class JavaOutputExample implements Output { +``` + +Notes about the class declaration: + +* All Java plugins must be annotated with the `@LogstashPlugin` annotation. Additionally: + + * The `name` property of the annotation must be supplied and defines the name of the plugin as it will be used in the Logstash pipeline definition. For example, this output would be referenced in the output section of the Logstash pipeline definition as `output { java_output_example => { .... } }` + * The value of the `name` property must match the name of the class excluding casing and underscores. + +* The class must implement the `co.elastic.logstash.api.Output` interface. +* Java plugins may not be created in the `org.logstash` or `co.elastic.logstash` packages to prevent potential clashes with classes in Logstash itself. + + +### Plugin settings [_plugin_settings_4] + +The snippet below contains both the setting definition and the method referencing it: + +```java +public static final PluginConfigSpec PREFIX_CONFIG = + PluginConfigSpec.stringSetting("prefix", ""); + +@Override +public Collection> configSchema() { + return Collections.singletonList(PREFIX_CONFIG); +} +``` + +The `PluginConfigSpec` class allows developers to specify the settings that a plugin supports complete with setting name, data type, deprecation status, required status, and default value. In this example, the `prefix` setting defines an optional prefix to include in the output of the event. The setting is not required and if it is not explicitly set, it defaults to the empty string. + +The `configSchema` method must return a list of all settings that the plugin supports. In a future phase of the Java plugin project, the Logstash execution engine will validate that all required settings are present and that no unsupported settings are present. + + +### Constructor and initialization [_constructor_and_initialization_4] + +```java +private final String id; +private String prefix; +private PrintStream printer; + +public JavaOutputExample(final String id, final Configuration configuration, final Context context) { + this(configuration, context, System.out); +} + +JavaOutputExample(final String id, final Configuration config, final Context context, OutputStream targetStream) { + this.id = id; + prefix = config.get(PREFIX_CONFIG); + printer = new PrintStream(targetStream); +} +``` + +All Java output plugins must have a constructor taking a `String` id and a `Configuration` and `Context` argument. This is the constructor that will be used to instantiate them at runtime. The retrieval and validation of all plugin settings should occur in this constructor. In this example, the values of the `prefix` setting is retrieved and stored in a local variable for later use in the `output` method. In this example, a second, pacakge private constructor is defined that is useful for unit testing with a `Stream` other than `System.out`. + +Any additional initialization may occur in the constructor as well. If there are any unrecoverable errors encountered in the configuration or initialization of the output plugin, a descriptive exception should be thrown. The exception will be logged and will prevent Logstash from starting. + + +### Output method [_output_method] + +```java +@Override +public void output(final Collection events) { + Iterator z = events.iterator(); + while (z.hasNext() && !stopped) { + String s = prefix + z.next(); + printer.println(s); + } +} +``` + +Outputs may send events to local sinks such as the console or a file or to remote systems such as Elasticsearch or other external systems. In this example, the events are printed to the local console. + + +### Stop and awaitStop methods [_stop_and_awaitstop_methods_2] + +```java +private final CountDownLatch done = new CountDownLatch(1); +private volatile boolean stopped; + +@Override +public void stop() { + stopped = true; + done.countDown(); +} + +@Override +public void awaitStop() throws InterruptedException { + done.await(); +} +``` + +The `stop` method notifies the output to stop sending events. The stop mechanism may be implemented in any way that honors the API contract though a `volatile boolean` flag works well for many use cases. Because this output example is so simple, its `output` method does not check for the stop flag. + +Outputs stop both asynchronously and cooperatively. Use the `awaitStop` method to block until the output has completed the stop process. Note that this method should **not** signal the output to stop as the `stop` method does. The awaitStop mechanism may be implemented in any way that honors the API contract though a `CountDownLatch` works well for many use cases. + + +### getId method [_getid_method_4] + +```java +@Override +public String getId() { + return id; +} +``` + +For output plugins, the `getId` method should always return the id that was provided to the plugin through its constructor at instantiation time. + + +### Unit tests [_unit_tests_4] + +Lastly, but certainly not least importantly, unit tests are strongly encouraged. The example output plugin includes an [example unit test](https://github.com/logstash-plugins/logstash-output-java_output_example/blob/main/src/test/java/org/logstashplugins/JavaOutputExampleTest.java) that you can use as a template for your own. + + +## Package and deploy [_package_and_deploy_4] + +Java plugins are packaged as Ruby gems for dependency management and interoperability with Ruby plugins. Once they are packaged as gems, they may be installed with the `logstash-plugin` utility just as Ruby plugins are. Because no knowledge of Ruby or its toolchain should be required for Java plugin development, the procedure for packaging Java plugins as Ruby gems has been automated through a custom task in the Gradle build file provided with the example Java plugins. The following sections describe how to configure and execute that packaging task as well as how to install the packaged Java plugin in Logstash. + + +### Configuring the Gradle packaging task [_configuring_the_gradle_packaging_task_4] + +The following section appears near the top of the `build.gradle` file supplied with the example Java plugins: + +```java +// =========================================================================== +// plugin info +// =========================================================================== +group 'org.logstashplugins' // must match the package of the main plugin class +version "${file("VERSION").text.trim()}" // read from required VERSION file +description = "Example Java filter implementation" +pluginInfo.licenses = ['Apache-2.0'] // list of SPDX license IDs +pluginInfo.longDescription = "This gem is a Logstash plugin required to be installed on top of the Logstash core pipeline using \$LS_HOME/bin/logstash-plugin install gemname. This gem is not a stand-alone program" +pluginInfo.authors = ['Elasticsearch'] +pluginInfo.email = ['info@elastic.co'] +pluginInfo.homepage = "http://www.elastic.co/guide/en/logstash/current/index.html" +pluginInfo.pluginType = "filter" +pluginInfo.pluginClass = "JavaFilterExample" +pluginInfo.pluginName = "java_filter_example" +// =========================================================================== +``` + +You should configure the values above for your plugin. + +* The `version` value will be automatically read from the `VERSION` file in the root of your plugin’s codebase. +* `pluginInfo.pluginType` should be set to one of `input`, `filter`, `codec`, or `output`. +* `pluginInfo.pluginName` must match the name specified on the `@LogstashPlugin` annotation on the main plugin class. The Gradle packaging task will validate that and return an error if they do not match. + + +### Running the Gradle packaging task [_running_the_gradle_packaging_task_4] + +Several Ruby source files along with a `gemspec` file and a `Gemfile` are required to package the plugin as a Ruby gem. These Ruby files are used only for defining the Ruby gem structure or at Logstash startup time to register the Java plugin. They are not used during runtime event processing. The Gradle packaging task automatically generates all of these files based on the values configured in the section above. + +You run the Gradle packaging task with the following command: + +```shell +./gradlew gem +``` + +For Windows platforms: Substitute `gradlew.bat` for `./gradlew` as appropriate in the command. + +That task will produce a gem file in the root directory of your plugin’s codebase with the name `logstash-{{plugintype}}--.gem` + + +### Installing the Java plugin in Logstash [_installing_the_java_plugin_in_logstash_4] + +After you have packaged your Java plugin as a Ruby gem, you can install it in Logstash with this command: + +```shell +bin/logstash-plugin install --no-verify --local /path/to/javaPlugin.gem +``` + +For Windows platforms: Substitute backslashes for forward slashes as appropriate in the command. + + +## Running Logstash with the Java output plugin [_running_logstash_with_the_java_output_plugin] + +The following is a minimal Logstash configuration that can be used to test that the Java output plugin is correctly installed and functioning. + +```java +input { + generator { message => "Hello world!" count => 1 } +} +output { + java_output_example {} +} +``` + +Copy the above Logstash configuration to a file such as `java_output.conf`. Logstash should then be started with: + +```txt +bin/logstash -f /path/to/java_output.conf +``` + +The expected Logstash output (excluding initialization) with the configuration above is: + +```txt +{"@timestamp":"yyyy-MM-ddTHH:mm:ss.SSSZ","message":"Hello world!","@version":"1","host":"","sequence":0} +``` + + +## Feedback [_feedback_4] + +If you have any feedback on Java plugin support in Logstash, please comment on our [main Github issue](https://github.com/elastic/logstash/issues/9215) or post in the [Logstash forum](https://discuss.elastic.co/c/logstash). diff --git a/docs/extend/output-new-plugin.md b/docs/extend/output-new-plugin.md new file mode 100644 index 000000000..88f9ef369 --- /dev/null +++ b/docs/extend/output-new-plugin.md @@ -0,0 +1,570 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/output-new-plugin.html +--- + +# How to write a Logstash output plugin [output-new-plugin] + +To develop a new output for Logstash, build a self-contained Ruby gem whose source code lives in its own GitHub repository. The Ruby gem can then be hosted and shared on RubyGems.org. You can use the example output implementation as a starting point. (If you’re unfamiliar with Ruby, you can find an excellent quickstart guide at [https://www.ruby-lang.org/en/documentation/quickstart/](https://www.ruby-lang.org/en/documentation/quickstart/).) + +## Get started [_get_started_4] + +Let’s step through creating an output plugin using the [example output plugin](https://github.com/logstash-plugins/logstash-output-example/). + +### Create a GitHub repo for your new plugin [_create_a_github_repo_for_your_new_plugin_4] + +Each Logstash plugin lives in its own GitHub repository. To create a new repository for your plugin: + +1. Log in to GitHub. +2. Click the **Repositories** tab. You’ll see a list of other repositories you’ve forked or contributed to. +3. Click the green **New** button in the upper right. +4. Specify the following settings for your new repo: + + * **Repository name** — a unique name of the form `logstash-output-pluginname`. + * **Public or Private** — your choice, but the repository must be Public if you want to submit it as an official plugin. + * **Initialize this repository with a README** — enables you to immediately clone the repository to your computer. + +5. Click **Create Repository**. + + +### Use the plugin generator tool [_use_the_plugin_generator_tool_4] + +You can create your own Logstash plugin in seconds! The `generate` subcommand of `bin/logstash-plugin` creates the foundation for a new Logstash plugin with templatized files. It creates the correct directory structure, gemspec files, and dependencies so you can start adding custom code to process data with Logstash. + +For more information, see [Generating plugins](/reference/plugin-generator.md) + + +### Copy the output code [_copy_the_output_code] + +Alternatively, you can use the examples repo we host on github.com + +1. **Clone your plugin.** Replace `GITUSERNAME` with your github username, and `MYPLUGINNAME` with your plugin name. + + * `git clone https://github.com/GITUSERNAME/logstash-``output-MYPLUGINNAME.git` + + * alternately, via ssh: `git clone git@github.com:GITUSERNAME/logstash``-output-MYPLUGINNAME.git` + + * `cd logstash-output-MYPLUGINNAME` + +2. **Clone the output plugin example and copy it to your plugin branch.** + + You don’t want to include the example .git directory or its contents, so delete it before you copy the example. + + * `cd /tmp` + * `git clone https://github.com/logstash-plugins/logstash``-output-example.git` + * `cd logstash-output-example` + * `rm -rf .git` + * `cp -R * /path/to/logstash-output-mypluginname/` + +3. **Rename the following files to match the name of your plugin.** + + * `logstash-output-example.gemspec` + * `example.rb` + * `example_spec.rb` + + ```txt + cd /path/to/logstash-output-mypluginname + mv logstash-output-example.gemspec logstash-output-mypluginname.gemspec + mv lib/logstash/outputs/example.rb lib/logstash/outputs/mypluginname.rb + mv spec/outputs/example_spec.rb spec/outputs/mypluginname_spec.rb + ``` + + +Your file structure should look like this: + +```txt +$ tree logstash-output-mypluginname +├── Gemfile +├── LICENSE +├── README.md +├── Rakefile +├── lib +│   └── logstash +│   └── outputs +│   └── mypluginname.rb +├── logstash-output-mypluginname.gemspec +└── spec + └── outputs + └── mypluginname_spec.rb +``` + +For more information about the Ruby gem file structure and an excellent walkthrough of the Ruby gem creation process, see [http://timelessrepo.com/making-ruby-gems](http://timelessrepo.com/making-ruby-gems) + + +### See what your plugin looks like [_see_what_your_plugin_looks_like_4] + +Before we dive into the details, open up the plugin file in your favorite text editor and take a look. + +```ruby +require "logstash/outputs/base" +require "logstash/namespace" + +# Add any asciidoc formatted documentation here +# An example output that does nothing. +class LogStash::Outputs::Example < LogStash::Outputs::Base + config_name "example" + + # This sets the concurrency behavior of this plugin. By default it is :legacy, which was the standard + # way concurrency worked before Logstash 2.4 + # + # You should explicitly set it to either :single or :shared as :legacy will be removed in Logstash 6.0 + # + # When configured as :single a single instance of the Output will be shared among the + # pipeline worker threads. Access to the `#multi_receive/#multi_receive_encoded/#receive` method will be synchronized + # i.e. only one thread will be active at a time making threadsafety much simpler. + # + # You can set this to :shared if your output is threadsafe. This will maximize + # concurrency but you will need to make appropriate uses of mutexes in `#multi_receive/#receive`. + # + # Only the `#multi_receive/#multi_receive_encoded` methods need to actually be threadsafe, the other methods + # will only be executed in a single thread + concurrency :single + + public + def register + end # def register + + public + # Takes an array of events + # Must be threadsafe if `concurrency :shared` is set + def multi_receive(events) + end # def multi_receive +end # class LogStash::Outputs::Example +``` + + + +## Coding output plugins [_coding_output_plugins] + +Now let’s take a line-by-line look at the example plugin. + +### `require` Statements [_require_statements_4] + +Logstash output plugins require parent classes defined in `logstash/outputs/base` and logstash/namespace: + +```ruby +require "logstash/outputs/base" +require "logstash/namespace" +``` + +Of course, the plugin you build may depend on other code, or even gems. Just put them here along with these Logstash dependencies. + + + +## Plugin Body [_plugin_body_4] + +Let’s go through the various elements of the plugin itself. + +### `class` Declaration [_class_declaration_4] + +The output plugin class should be a subclass of `LogStash::Outputs::Base`: + +```ruby +class LogStash::Outputs::Example < LogStash::Outputs::Base +``` + +The class name should closely mirror the plugin name, for example: + +```ruby +LogStash::Outputs::Example +``` + + +### `config_name` [_config_name_4] + +```ruby + config_name "example" +``` + +This is the name your plugin will call inside the output configuration block. + +If you set `config_name "example"` in your plugin code, the corresponding Logstash configuration block would need to look like this: + + + +## Configuration Parameters [_configuration_parameters_4] + +```ruby + config :variable_name, :validate => :variable_type, :default => "Default value", :required => boolean, :deprecated => boolean, :obsolete => string +``` + +The configuration, or `config` section allows you to define as many (or as few) parameters as are needed to enable Logstash to process events. + +There are several configuration attributes: + +* `:validate` - allows you to enforce passing a particular data type to Logstash for this configuration option, such as `:string`, `:password`, `:boolean`, `:number`, `:array`, `:hash`, `:path` (a file-system path), `uri`, `:codec` (since 1.2.0), `:bytes`. Note that this also works as a coercion in that if I specify "true" for boolean (even though technically a string), it will become a valid boolean in the config. This coercion works for the `:number` type as well where "1.2" becomes a float and "22" is an integer. +* `:default` - lets you specify a default value for a parameter +* `:required` - whether or not this parameter is mandatory (a Boolean `true` or +* `:list` - whether or not this value should be a list of values. Will typecheck the list members, and convert scalars to one element lists. Note that this mostly obviates the array type, though if you need lists of complex objects that will be more suitable. `false`) +* `:deprecated` - informational (also a Boolean `true` or `false`) +* `:obsolete` - used to declare that a given setting has been removed and is no longer functioning. The idea is to provide an informed upgrade path to users who are still using a now-removed setting. + + +## Plugin Methods [_plugin_methods_4] + +Logstash outputs must implement the `register` and `multi_receive` methods. + +### `register` Method [_register_method_4] + +```ruby + public + def register + end # def register +``` + +The Logstash `register` method is like an `initialize` method. It was originally created to enforce having `super` called, preventing headaches for newbies. (Note: It may go away in favor of `initialize`, in conjunction with some enforced testing to ensure `super` is called.) + +`public` means the method can be called anywhere, not just within the class. This is the default behavior for methods in Ruby, but it is specified explicitly here anyway. + +You can also assign instance variables here (variables prepended by `@`). Configuration variables are now in scope as instance variables, like `@message` + + + +## Building the Plugin [_building_the_plugin_4] + +At this point in the process you have coded your plugin and are ready to build a Ruby Gem from it. The following information will help you complete the process. + +### External dependencies [_external_dependencies_4] + +A `require` statement in Ruby is used to include necessary code. In some cases your plugin may require additional files. For example, the collectd plugin [uses](https://github.com/logstash-plugins/logstash-codec-collectd/blob/main/lib/logstash/codecs/collectd.rb#L148) the `types.db` file provided by collectd. In the main directory of your plugin, a file called `vendor.json` is where these files are described. + +The `vendor.json` file contains an array of JSON objects, each describing a file dependency. This example comes from the [collectd](https://github.com/logstash-plugins/logstash-codec-collectd/blob/main/vendor.json) codec plugin: + +```txt +[{ + "sha1": "a90fe6cc53b76b7bdd56dc57950d90787cb9c96e", + "url": "http://collectd.org/files/collectd-5.4.0.tar.gz", + "files": [ "/src/types.db" ] +}] +``` + +* `sha1` is the sha1 signature used to verify the integrity of the file referenced by `url`. +* `url` is the address from where Logstash will download the file. +* `files` is an optional array of files to extract from the downloaded file. Note that while tar archives can use absolute or relative paths, treat them as absolute in this array. If `files` is not present, all files will be uncompressed and extracted into the vendor directory. + +Another example of the `vendor.json` file is the [`geoip` filter](https://github.com/logstash-plugins/logstash-filter-geoip/blob/main/vendor.json) + +The process used to download these dependencies is to call `rake vendor`. This will be discussed further in the testing section of this document. + +Another kind of external dependency is on jar files. This will be described in the "Add a `gemspec` file" section. + + +### Deprecated features [_deprecated_features_4] + +As a plugin evolves, an option or feature may no longer serve the intended purpose, and the developer may want to *deprecate* its usage. Deprecation warns users about the option’s status, so they aren’t caught by surprise when it is removed in a later release. + +{{ls}} 7.6 introduced a *deprecation logger* to make handling those situations easier. You can use the [adapter](https://github.com/logstash-plugins/logstash-mixin-deprecation_logger_support) to ensure that your plugin can use the deprecation logger while still supporting older versions of {{ls}}. See the [readme](https://github.com/logstash-plugins/logstash-mixin-deprecation_logger_support/blob/main/README.md) for more information and for instructions on using the adapter. + +Deprecations are noted in the `logstash-deprecation.log` file in the `log` directory. + + +### Add a Gemfile [_add_a_gemfile_4] + +Gemfiles allow Ruby’s Bundler to maintain the dependencies for your plugin. Currently, all we’ll need is the Logstash gem, for testing, but if you require other gems, you should add them in here. + +::::{tip} +See [Bundler’s Gemfile page](http://bundler.io/gemfile.html) for more details. +:::: + + +```ruby +source 'https://rubygems.org' +gemspec +gem "logstash", :github => "elastic/logstash", :branch => "master" +``` + + + +## Add a `gemspec` file [_add_a_gemspec_file_4] + +Gemspecs define the Ruby gem which will be built and contain your plugin. + +::::{tip} +More information can be found on the [Rubygems Specification page](http://guides.rubygems.org/specification-reference/). +:::: + + +```ruby +Gem::Specification.new do |s| + s.name = 'logstash-output-example' + s.version = '0.1.0' + s.licenses = ['Apache License (2.0)'] + s.summary = "This output does x, y, z in Logstash" + s.description = "This gem is a logstash plugin required to be installed on top of the Logstash core pipeline using $LS_HOME/bin/logstash-plugin install gemname. This gem is not a stand-alone program" + s.authors = ["Elastic"] + s.email = 'info@elastic.co' + s.homepage = "http://www.elastic.co/guide/en/logstash/current/index.html" + s.require_paths = ["lib"] + + # Files + s.files = Dir['lib/**/*','spec/**/*','vendor/**/*','*.gemspec','*.md','CONTRIBUTORS','Gemfile','LICENSE','NOTICE.TXT'] + # Tests + s.test_files = s.files.grep(%r{^(test|spec|features)/}) + + # Special flag to let us know this is actually a logstash plugin + s.metadata = { "logstash_plugin" => "true", "logstash_group" => "output" } + + # Gem dependencies + s.add_runtime_dependency "logstash-core-plugin-api", ">= 1.60", "<= 2.99" + s.add_development_dependency 'logstash-devutils' +end +``` + +It is appropriate to change these values to fit your plugin. In particular, `s.name` and `s.summary` should reflect your plugin’s name and behavior. + +`s.licenses` and `s.version` are also important and will come into play when you are ready to publish your plugin. + +Logstash and all its plugins are licensed under [Apache License, version 2 ("ALv2")](https://github.com/elastic/logstash/blob/main/LICENSE.txt). If you make your plugin publicly available via [RubyGems.org](http://rubygems.org), please make sure to have this line in your gemspec: + +* `s.licenses = ['Apache License (2.0)']` + +The gem version, designated by `s.version`, helps track changes to plugins over time. You should use [semver versioning](http://semver.org/) strategy for version numbers. + +### Runtime and Development Dependencies [_runtime_and_development_dependencies_4] + +At the bottom of the `gemspec` file is a section with a comment: `Gem dependencies`. This is where any other needed gems must be mentioned. If a gem is necessary for your plugin to function, it is a runtime dependency. If a gem are only used for testing, then it would be a development dependency. + +::::{note} +You can also have versioning requirements for your dependencies—​including other Logstash plugins: + +```ruby + # Gem dependencies + s.add_runtime_dependency "logstash-core-plugin-api", ">= 1.60", "<= 2.99" + s.add_development_dependency 'logstash-devutils' +``` + +This gemspec has a runtime dependency on the logstash-core-plugin-api and requires that it have a version number greater than or equal to version 1.60 and less than or equal to version 2.99. + +:::: + + +::::{important} +All plugins have a runtime dependency on the `logstash-core-plugin-api` gem, and a development dependency on `logstash-devutils`. +:::: + + + +### Jar dependencies [_jar_dependencies_4] + +In some cases, such as the [Elasticsearch output plugin](https://github.com/logstash-plugins/logstash-output-elasticsearch/blob/main/logstash-output-elasticsearch.gemspec#L22-L23), your code may depend on a jar file. In cases such as this, the dependency is added in the gemspec file in this manner: + +```ruby + # Jar dependencies + s.requirements << "jar 'org.elasticsearch:elasticsearch', '5.0.0'" + s.add_runtime_dependency 'jar-dependencies' +``` + +With these both defined, the install process will search for the required jar file at [http://mvnrepository.com](http://mvnrepository.com) and download the specified version. + + + +## Document your plugin [_document_your_plugin_4] + +Documentation is an important part of your plugin. All plugin documentation is rendered and placed in the [Logstash Reference](/reference/index.md) and the [Versioned plugin docs](logstash-docs://reference/integration-plugins.md). + +See [Document your plugin](/extend/plugin-doc.md) for tips and guidelines. + + +## Add Tests [_add_tests_4] + +Logstash loves tests. Lots of tests. If you’re using your new output plugin in a production environment, you’ll want to have some tests to ensure you are not breaking any existing functionality. + +::::{note} +A full exposition on RSpec is outside the scope of this document. Learn more about RSpec at [http://rspec.info](http://rspec.info) +:::: + + +For help learning about tests and testing, look in the `spec/outputs/` directory of several other similar plugins. + + +## Clone and test! [_clone_and_test_4] + +Now let’s start with a fresh clone of the plugin, build it and run the tests. + +* **Clone your plugin into a temporary location** Replace `GITUSERNAME` with your github username, and `MYPLUGINNAME` with your plugin name. + + * `git clone https://github.com/GITUSERNAME/logstash-``output-MYPLUGINNAME.git` + + * alternately, via ssh: `git clone git@github.com:GITUSERNAME/logstash-``output-MYPLUGINNAME.git` + + * `cd logstash-output-MYPLUGINNAME` + + +Then, you’ll need to install your plugins dependencies with bundler: + +``` +bundle install +``` + +::::{important} +If your plugin has an external file dependency described in `vendor.json`, you must download that dependency before running or testing. You can do this by running: + +``` +rake vendor +``` + +:::: + + +And finally, run the tests: + +``` +bundle exec rspec +``` + +You should see a success message, which looks something like this: + +``` +Finished in 0.034 seconds +1 example, 0 failures +``` + +Hooray! You’re almost there! (Unless you saw failures…​ you should fix those first). + + +## Building and Testing [_building_and_testing_4] + +Now you’re ready to build your (well-tested) plugin into a Ruby gem. + +### Build [_build_4] + +You already have all the necessary ingredients, so let’s go ahead and run the build command: + +```sh +gem build logstash-output-example.gemspec +``` + +That’s it! Your gem should be built and be in the same path with the name + +```sh +logstash-output-mypluginname-0.1.0.gem +``` + +The `s.version` number from your gemspec file will provide the gem version, in this case, `0.1.0`. + + +### Test installation [_test_installation_4] + +You should test install your plugin into a clean installation of Logstash. Download the latest version from the [Logstash downloads page](https://www.elastic.co/downloads/logstash/). + +1. Untar and cd in to the directory: + + ```sh + curl -O https://download.elastic.co/logstash/logstash/logstash-9.0.0.tar.gz + tar xzvf logstash-9.0.0.tar.gz + cd logstash-9.0.0 + ``` + +2. Using the plugin tool, we can install the gem we just built. + + * Replace `/my/logstash/plugins` with the correct path to the gem for your environment, and `0.1.0` with the correct version number from the gemspec file. + + ```sh + bin/logstash-plugin install /my/logstash/plugins/logstash-output-example/logstash-output-example-0.1.0.gem + ``` + + * After running this, you should see feedback from Logstash that it was successfully installed: + + ```sh + validating /my/logstash/plugins/logstash-output-example/logstash-output-example-0.1.0.gem >= 0 + Valid logstash plugin. Continuing... + Successfully installed 'logstash-output-example' with version '0.1.0' + ``` + + ::::{tip} + You can also use the Logstash plugin tool to determine which plugins are currently available: + + ```sh + bin/logstash-plugin list + ``` + + Depending on what you have installed, you might see a short or long list of plugins: inputs, codecs, filters and outputs. + + :::: + +3. Now try running Logstash with a simple configuration passed in via the command-line, using the `-e` flag. + + ::::{note} + Your results will depend on what your output plugin is designed to do. + :::: + + +Congratulations! You’ve built, deployed and successfully run a Logstash output. + + + +## Submitting your plugin to [RubyGems.org](http://rubygems.org) and [logstash-plugins](https://github.com/logstash-plugins) [_submitting_your_plugin_to_rubygems_orghttprubygems_org_and_logstash_pluginshttpsgithub_comlogstash_plugins_4] + +Logstash uses [RubyGems.org](http://rubygems.org) as its repository for all plugin artifacts. Once you have developed your new plugin, you can make it available to Logstash users by simply publishing it to RubyGems.org. + +### Licensing [_licensing_4] + +Logstash and all its plugins are licensed under [Apache License, version 2 ("ALv2")](https://github.com/elasticsearch/logstash/blob/main/LICENSE). If you make your plugin publicly available via [RubyGems.org](http://rubygems.org), please make sure to have this line in your gemspec: + +* `s.licenses = ['Apache License (2.0)']` + + +### Publishing to [RubyGems.org](http://rubygems.org) [_publishing_to_rubygems_orghttprubygems_org_4] + +To begin, you’ll need an account on RubyGems.org + +* [Sign-up for a RubyGems account](https://rubygems.org/sign_up). + +After creating an account, [obtain](http://guides.rubygems.org/rubygems-org-api/#api-authorization) an API key from RubyGems.org. By default, RubyGems uses the file `~/.gem/credentials` to store your API key. These credentials will be used to publish the gem. Replace `username` and `password` with the credentials you created at RubyGems.org: + +```sh +curl -u username:password https://rubygems.org/api/v1/api_key.yaml > ~/.gem/credentials +chmod 0600 ~/.gem/credentials +``` + +Before proceeding, make sure you have the right version in your gemspec file and commit your changes. + +* `s.version = '0.1.0'` + +To publish version 0.1.0 of your new logstash gem: + +```sh +bundle install +bundle exec rake vendor +bundle exec rspec +bundle exec rake publish_gem +``` + +::::{note} +Executing `rake publish_gem`: + +1. Reads the version from the gemspec file (`s.version = '0.1.0'`) +2. Checks in your local repository if a tag exists for that version. If the tag already exists, it aborts the process. Otherwise, it creates a new version tag in your local repository. +3. Builds the gem +4. Publishes the gem to RubyGems.org + +:::: + + +That’s it! Your plugin is published! Logstash users can now install your plugin by running: + +```sh +bin/logstash-plugin install logstash-output-mypluginname +``` + + + +## Contributing your source code to [logstash-plugins](https://github.com/logstash-plugins) [_contributing_your_source_code_to_logstash_pluginshttpsgithub_comlogstash_plugins_4] + +It is not required to contribute your source code to [logstash-plugins](https://github.com/logstash-plugins) github organization, but we always welcome new plugins! + +### Benefits [_benefits_4] + +Some of the many benefits of having your plugin in the logstash-plugins repository are: + +* **Discovery.** Your plugin will appear in the [Logstash Reference](/reference/index.md), where Logstash users look first for plugins and documentation. +* **Documentation.** Your plugin documentation will automatically be added to the [Logstash Reference](/reference/index.md). +* **Testing.** With our testing infrastructure, your plugin will be continuously tested against current and future releases of Logstash. As a result, users will have the assurance that if incompatibilities arise, they will be quickly discovered and corrected. + + +### Acceptance Guidelines [_acceptance_guidelines_4] + +* **Code Review.** Your plugin must be reviewed by members of the community for coherence, quality, readability, stability and security. +* **Tests.** Your plugin must contain tests to be accepted. These tests are also subject to code review for scope and completeness. It’s ok if you don’t know how to write tests — we will guide you. We are working on publishing a guide to creating tests for Logstash which will make it easier. In the meantime, you can refer to [http://betterspecs.org/](http://betterspecs.org/) for examples. + +To begin migrating your plugin to logstash-plugins, simply create a new [issue](https://github.com/elasticsearch/logstash/issues) in the Logstash repository. When the acceptance guidelines are completed, we will facilitate the move to the logstash-plugins organization using the recommended [github process](https://help.github.com/articles/transferring-a-repository/#transferring-from-a-user-to-an-organization). diff --git a/docs/extend/plugin-doc.md b/docs/extend/plugin-doc.md new file mode 100644 index 000000000..b3c4b3271 --- /dev/null +++ b/docs/extend/plugin-doc.md @@ -0,0 +1,172 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/plugin-doc.html +--- + +# Document your plugin [plugin-doc] + +Documentation is a required component of your plugin. Quality documentation with good examples contributes to the adoption of your plugin. + +The documentation that you write for your plugin will be generated and published in the [Logstash Reference](/reference/index.md) and the [Logstash Versioned Plugin Reference](logstash-docs://reference/integration-plugins.md). + +::::{admonition} Plugin listing in {{ls}} Reference +:class: note + +We may list your plugin in the [Logstash Reference](/reference/index.md) if it meets our [requirements and quality standards](/extend/index.md#plugin-acceptance). When we list your plugin, we point to *your* documentation—​a readme.md, docs/index.asciidoc, or both—​in your plugin repo. For more info on this option, see [List your plugin](/extend/plugin-listing.md). + +:::: + + +The following sections contain guidelines for documenting plugins hosted in the Github [logstash-plugins](https://github.com/logstash-plugins/) organization. + +## Documentation file [plugin-doc-file] + +Documentation belongs in a single file called *docs/index.asciidoc*. It belongs in a single file called *docs/index.asciidoc*. The [plugin generation utility](/reference/plugin-generator.md) creates a starter file for you. + + +## Heading IDs [heading-ids] + +Format heading anchors with variables that can support generated IDs. This approach creates unique IDs when the [Logstash Versioned Plugin Reference](logstash-docs://reference/integration-plugins.md) is built. Unique heading IDs are required to avoid duplication over multiple versions of a plugin. + +**Example** + +Don’t hardcode a plugin heading ID like this: `[[config_models]]` + +Instead, use variables to define it: + +```txt +[id="plugins-{type}s-{plugin}-config_models"] +==== Configuration models +``` + +If you hardcode an ID, the [Logstash Versioned Plugin Reference](logstash-docs://reference/integration-plugins.md) builds correctly the first time. The second time the doc build runs, the ID is flagged as a duplicate, and the build fails. + + +## Link formats [link-format] + +Correct link formatting is essential for directing users to the content you want them to see. Incorrect link formatting or duplicate links can break the documentation build. Let’s not do that. + +### Link to content in the same file [_link_to_content_in_the_same_file] + +Use angle brackets to format links to content in the same asciidoc file. + +**Example** + +This link: + +```txt +<> +``` + +Points to this heading in the same file: + +```txt +[id="plugins-{type}s-{plugin}-config_models"] +==== Configuration models +``` + + +### Link to content in the Logstash Reference Guide [_link_to_content_in_the_logstash_reference_guide] + +Use external link syntax for links that point to documentation for other plugins or content in the Logstash Reference Guide. + +**Examples** + +```txt +{logstash-ref}/plugins-codecs-multiline.html[Multiline codec plugin] +``` + +```txt +{logstash-ref}/getting-started-with-logstash.html +``` + + +### Link text [_link_text] + +If you don’t specify link text, the URL is used as the link text. + +**Examples** + +If you want your link to display as {{logstash-ref}}/getting-started-with-logstash.html, use this format: + +```txt +{logstash-ref}/getting-started-with-logstash.html +``` + +If you want your link to display as [Getting Started with Logstash](/reference/getting-started-with-logstash.md), use this format: + +```txt +{logstash-ref}/getting-started-with-logstash.html[Getting Started with Logstash] +``` + + +### Link to data type descriptions [_link_to_data_type_descriptions] + +We make an exception for links that point to data type descriptions, such as `<>`, because they are used so frequently. We have a cleanup step in the conversion script that converts the links to the correct syntax. + + + +## Code samples [format-code] + +We all love code samples. Asciidoc supports code blocks and config examples. To include Ruby code, use the asciidoc `[source,ruby]` directive. + +Note that the hashmarks (#) are present to make the example render correctly. Don’t include the hashmarks in your asciidoc file. + +```txt +# [source,ruby] +# ----- +# match => { +# "field1" => "value1" +# "field2" => "value2" +# ... +# } +# ----- +``` + +The sample above (with hashmarks removed) renders in the documentation like this: + +```ruby +match => { + "field1" => "value1" + "field2" => "value2" + ... +} +``` + + +## Where’s my doc? [_wheres_my_doc] + +Plugin documentation goes through several steps before it gets published in the [Logstash Versioned Plugin Reference](logstash-docs://reference/integration-plugins.md) and the [Logstash Reference](/reference/index.md). + +Here’s an overview of the workflow: + +* Be sure that you have signed the contributor license agreement (CLA) and have all necessary approvals and sign offs. +* Merge the pull request for your plugin (including the `index.asciidoc` file, the `changelog.md` file, and the gemspec). +* Wait for the continuous integration build to complete successfully. +* Publish the plugin to [https://rubygems.org](https://rubygems.org). +* A script detects the new or changed version, and picks up the `index.asciidoc` file for inclusion in the doc build. +* The documentation for your new plugin is published in the [Logstash Versioned Plugin Reference](logstash-docs://reference/integration-plugins.md). + +We’re not done yet. + +* For each release, we package the new and changed documentation files into a pull request to add or update content. (We sometimes package plugin docs between releases if we make significant changes to plugin documentation or add a new plugin.) +* The script detects the new or changed version, and picks up the `index.asciidoc` file for inclusion in the doc build. +* We create a pull request, and merge the new and changed content into the appropriate version branches. +* For a new plugin, we add a link to the list of plugins in the [Logstash Reference](/reference/index.md). +* The documentation for your new (or changed) plugin is published in the [Logstash Reference](/reference/index.md). + +### Documentation or plugin updates [_documentation_or_plugin_updates] + +When you make updates to your plugin or the documentation, consider bumping the version number in the changelog and gemspec (or version file). The version change triggers the doc build to pick up your changes for publishing. + + + +## Resources [_resources] + +For more asciidoc formatting tips, see the excellent reference at [https://github.com/elastic/docs#asciidoc-guide](https://github.com/elastic/docs#asciidoc-guide). + +For tips on contributing and changelog guidelines, see [CONTRIBUTING.md](https://github.com/elastic/logstash/blob/main/CONTRIBUTING.md#logstash-plugin-changelog-guidelines). + +For general information about contributing, see [Contributing to Logstash](/extend/index.md). + + diff --git a/docs/extend/plugin-listing.md b/docs/extend/plugin-listing.md new file mode 100644 index 000000000..48807a404 --- /dev/null +++ b/docs/extend/plugin-listing.md @@ -0,0 +1,23 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/plugin-listing.html +--- + +# List your plugin [plugin-listing] + +The [Logstash Reference](/reference/index.md) is the first place {{ls}} users look for plugins and documentation. If your plugin meets the [quality and acceptance guidelines](/extend/index.md#plugin-acceptance), we may be able to list it in the guide. + +The plugin source and documentation will continue to live in your repo, and we will direct users there. + +If you would like to have your plugin included in the [Logstash Reference](/reference/index.md), create a new [issue](https://github.com/elasticsearch/logstash/issues) in the Logstash repository with the following information: + +* Title: `PluginListing: ` +* Body: + + * Brief description of the plugin (what it is and what it does). + * Link to the plugin repository. + * Link to the README.md or docs/index.asciidoc. + * Describe how your plugin meets our [quality and acceptance guidelines](/extend/index.md#plugin-acceptance). + +* Labels: `docs`, `new-plugin` + diff --git a/docs/extend/publish-plugin.md b/docs/extend/publish-plugin.md new file mode 100644 index 000000000..13294b2b5 --- /dev/null +++ b/docs/extend/publish-plugin.md @@ -0,0 +1,62 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/publish-plugin.html +--- + +# Publish your plugin to RubyGems.org [publish-plugin] + +Logstash uses [RubyGems.org](http://rubygems.org) as its repository for all plugin artifacts. After you have developed your new plugin, you can make it available to Logstash users by publishing it to RubyGems.org. + +## Licensing [_licensing_5] + +Logstash and all its plugins are licensed under [Apache License, version 2 ("ALv2")](https://github.com/elasticsearch/logstash/blob/main/LICENSE). If you make your plugin publicly available via [RubyGems.org](http://rubygems.org), please make sure to have this line in your gemspec: + +* `s.licenses = ['Apache License (2.0)']` + + +## Publish to [RubyGems.org](http://rubygems.org) [_publish_to_rubygems_orghttprubygems_org] + +You’ll need an account on RubyGems.org + +* [Sign-up for a RubyGems account](https://rubygems.org/sign_up). + +After creating an account, [obtain](http://guides.rubygems.org/rubygems-org-api/#api-authorization) an API key from RubyGems.org. By default, RubyGems uses the file `~/.gem/credentials` to store your API key. These credentials will be used to publish the gem. Replace `username` and `password` with the credentials you created at RubyGems.org: + +```sh +curl -u username:password https://rubygems.org/api/v1/api_key.yaml > ~/.gem/credentials +chmod 0600 ~/.gem/credentials +``` + +Before proceeding, make sure you have the right version in your gemspec file and commit your changes. + +* `s.version = '0.1.0'` + +To publish version 0.1.0 of your new logstash gem: + +```sh +bundle install +bundle exec rake vendor +bundle exec rspec +bundle exec rake publish_gem +``` + +::::{note} +Execute `rake publish_gem`: + +1. Reads the version from the gemspec file (`s.version = '0.1.0'`) +2. Checks in your local repository if a tag exists for that version. If the tag already exists, it aborts the process. Otherwise, it creates a new version tag in your local repository. +3. Builds the gem +4. Publishes the gem to RubyGems.org + +:::: + + +That’s it! Your plugin is published! Logstash users can now install your plugin by running: + +```sh +bin/plugin install logstash-output-mypluginname +``` + +Where is `input`, `output`, `filter`, or `codec`, and is the name of your new plugin. + + diff --git a/docs/extend/toc.yml b/docs/extend/toc.yml new file mode 100644 index 000000000..225f36590 --- /dev/null +++ b/docs/extend/toc.yml @@ -0,0 +1,18 @@ +toc: + - file: index.md + - file: input-new-plugin.md + - file: codec-new-plugin.md + - file: filter-new-plugin.md + - file: output-new-plugin.md + - file: community-maintainer.md + - file: plugin-doc.md + - file: publish-plugin.md + - file: plugin-listing.md + - file: contributing-patch-plugin.md + - file: contribute-to-core.md + - file: create-logstash-plugins.md + children: + - file: java-input-plugin.md + - file: java-codec-plugin.md + - file: java-filter-plugin.md + - file: java-output-plugin.md \ No newline at end of file diff --git a/docs/gs-index.asciidoc b/docs/gs-index.asciidoc deleted file mode 100644 index feec48b87..000000000 --- a/docs/gs-index.asciidoc +++ /dev/null @@ -1,38 +0,0 @@ -[[logstash-reference]] -= Logstash Reference - -:branch: 5.4 -:major-version: 5.4 -:logstash_version: 5.4.0 -:elasticsearch_version: 5.4.0 -:docker-image: docker.elastic.co/logstash/logstash:{logstash_version} - -////////// -release-state can be: released | prerelease | unreleased -////////// -:release-state: released - -:jdk: 1.8.0 -:guide: https://www.elastic.co/guide/en/elasticsearch/guide/current/ -:ref: https://www.elastic.co/guide/en/elasticsearch/reference/{branch}/ -:xpack: https://www.elastic.co/guide/en/x-pack/{branch}/ -:logstash: https://www.elastic.co/guide/en/logstash/{branch}/ -:filebeat: https://www.elastic.co/guide/en/beats/filebeat/{branch}/ -:lsissue: https://github.com/elastic/logstash/issues/ -:security: X-Pack Security - -[[introduction]] -== Logstash Introduction - -Logstash is an open source data collection engine with real-time pipelining capabilities. Logstash can dynamically -unify data from disparate sources and normalize the data into destinations of your choice. Cleanse and democratize all -your data for diverse advanced downstream analytics and visualization use cases. - -While Logstash originally drove innovation in log collection, its capabilities extend well beyond that use case. Any -type of event can be enriched and transformed with a broad array of input, filter, and output plugins, with many -native codecs further simplifying the ingestion process. Logstash accelerates your insights by harnessing a greater -volume and variety of data. - -include::static/introduction.asciidoc[] - -include::static/getting-started-with-logstash.asciidoc[] \ No newline at end of file diff --git a/docs/static/images/basic_logstash_pipeline.png b/docs/images/basic_logstash_pipeline.png similarity index 100% rename from docs/static/images/basic_logstash_pipeline.png rename to docs/images/basic_logstash_pipeline.png diff --git a/docs/static/management/images/centralized_config.png b/docs/images/centralized_config.png similarity index 100% rename from docs/static/management/images/centralized_config.png rename to docs/images/centralized_config.png diff --git a/docs/static/images/dead_letter_queue.png b/docs/images/dead_letter_queue.png similarity index 100% rename from docs/static/images/dead_letter_queue.png rename to docs/images/dead_letter_queue.png diff --git a/docs/static/images/deploy1.png b/docs/images/deploy1.png similarity index 100% rename from docs/static/images/deploy1.png rename to docs/images/deploy1.png diff --git a/docs/static/images/deploy2.png b/docs/images/deploy2.png similarity index 100% rename from docs/static/images/deploy2.png rename to docs/images/deploy2.png diff --git a/docs/static/images/deploy3.png b/docs/images/deploy3.png similarity index 100% rename from docs/static/images/deploy3.png rename to docs/images/deploy3.png diff --git a/docs/static/images/deploy4.png b/docs/images/deploy4.png similarity index 100% rename from docs/static/images/deploy4.png rename to docs/images/deploy4.png diff --git a/docs/static/monitoring/images/integration-assets-dashboards.png b/docs/images/integration-assets-dashboards.png similarity index 100% rename from docs/static/monitoring/images/integration-assets-dashboards.png rename to docs/images/integration-assets-dashboards.png diff --git a/docs/static/monitoring/images/integration-dashboard-overview.png b/docs/images/integration-dashboard-overview.png similarity index 100% rename from docs/static/monitoring/images/integration-dashboard-overview.png rename to docs/images/integration-dashboard-overview.png diff --git a/docs/static/images/kibana-filebeat-data.png b/docs/images/kibana-filebeat-data.png similarity index 100% rename from docs/static/images/kibana-filebeat-data.png rename to docs/images/kibana-filebeat-data.png diff --git a/docs/static/monitoring/images/kibana-home.png b/docs/images/kibana-home.png similarity index 100% rename from docs/static/monitoring/images/kibana-home.png rename to docs/images/kibana-home.png diff --git a/docs/static/monitoring/images/monitoring-ui.png b/docs/images/monitoring-ui.png similarity index 100% rename from docs/static/monitoring/images/monitoring-ui.png rename to docs/images/monitoring-ui.png diff --git a/docs/static/monitoring/images/nodestats.png b/docs/images/nodestats.png similarity index 100% rename from docs/static/monitoring/images/nodestats.png rename to docs/images/nodestats.png diff --git a/docs/static/monitoring/images/overviewstats.png b/docs/images/overviewstats.png similarity index 100% rename from docs/static/monitoring/images/overviewstats.png rename to docs/images/overviewstats.png diff --git a/docs/static/monitoring/images/pipeline-input-detail.png b/docs/images/pipeline-input-detail.png similarity index 100% rename from docs/static/monitoring/images/pipeline-input-detail.png rename to docs/images/pipeline-input-detail.png diff --git a/docs/static/monitoring/images/pipeline-tree.png b/docs/images/pipeline-tree.png similarity index 100% rename from docs/static/monitoring/images/pipeline-tree.png rename to docs/images/pipeline-tree.png diff --git a/docs/static/images/pipeline_correct_load.png b/docs/images/pipeline_correct_load.png similarity index 100% rename from docs/static/images/pipeline_correct_load.png rename to docs/images/pipeline_correct_load.png diff --git a/docs/static/images/pipeline_overload.png b/docs/images/pipeline_overload.png similarity index 100% rename from docs/static/images/pipeline_overload.png rename to docs/images/pipeline_overload.png diff --git a/docs/include/attributes-ls.asciidoc b/docs/include/attributes-ls.asciidoc deleted file mode 100644 index 714982cad..000000000 --- a/docs/include/attributes-ls.asciidoc +++ /dev/null @@ -1,10 +0,0 @@ -///// -These settings control attributes for Logstash core content -in the Logstash Reference (LSR) only. - -Shared attributes for the plugin docs (in the LSR and VPR) should -go in /docs/include/attributes-lsplugins.asciidoc instead -with a corresponding change to the VPR settings in -logstash-docs/docs/versioned-plugins/include/attributes-ls-vpr.asciidoc -///// - diff --git a/docs/include/attributes-lsplugins.asciidoc b/docs/include/attributes-lsplugins.asciidoc deleted file mode 100644 index 674bcc03c..000000000 --- a/docs/include/attributes-lsplugins.asciidoc +++ /dev/null @@ -1,13 +0,0 @@ -///// -These settings control attributes in the LSR only. -They correspond to the VPR settings in logstash-docs/docs/versioned-plugins/include/attributes-ls-vpr.asciidoc -When we update one, we must update settings in the other location, - -Attribute text formatted without hard wrap is deliberate. -Otherwise, text breaks at return and content after the return is dropped. - -Text is written to accommodate multiple versions because plugins are not stack versioned. -///// - - -:ecs-default: When the `ecs_compatibility` option for this plugin is not explicitly set, its effective value depends on the `pipeline.ecs_compatibility` setting for the pipeline in `pipelines.yml`, or globally in {logstash-ref}/logstash-settings-file.html[`logstash.yml`], allowing you to specify your preferred behavior at the plugin, pipeline, or system level. If no preference is specified, the default value is `v8` for Logstash 8 or `disabled` for all earlier releases of Logstash. For more information about ECS compatibility settings in Logstash and plugins, see {logstash-ref}/ecs-ls.html[ECS in Logstash]. diff --git a/docs/include/filter.asciidoc b/docs/include/filter.asciidoc deleted file mode 100644 index 9cd984f29..000000000 --- a/docs/include/filter.asciidoc +++ /dev/null @@ -1,234 +0,0 @@ -==== Common options - -// Contributors: You must conditionally code all internal links and IDs in this -// file to make the common files work in both the LS Reference and the versioned -// plugin docs - -These configuration options are supported by all filter plugins: - -ifeval::["{versioned_docs}"!="true"] -[cols="<,<,<",options="header",] -|======================================================================= -|Setting |Input type|Required -| <> |{logstash-ref}/configuration-file-structure.html#hash[hash]|No -| <> |{logstash-ref}/configuration-file-structure.html#array[array]|No -| <> |{logstash-ref}/configuration-file-structure.html#boolean[boolean]|No -| <> |{logstash-ref}/configuration-file-structure.html#string[string]|No -| <> |{logstash-ref}/configuration-file-structure.html#boolean[boolean]|No -| <> |{logstash-ref}/configuration-file-structure.html#array[array]|No -| <> |{logstash-ref}/configuration-file-structure.html#array[array]|No -|======================================================================= -endif::[] -ifeval::["{versioned_docs}"=="true"] -[cols="<,<,<",options="header",] -|======================================================================= -|Setting |Input type|Required -| <<{version}-plugins-{type}s-{plugin}-add_field>> |{logstash-ref}/configuration-file-structure.html#hash[hash]|No -| <<{version}-plugins-{type}s-{plugin}-add_tag>> |{logstash-ref}/configuration-file-structure.html#array[array]|No -| <<{version}-plugins-{type}s-{plugin}-enable_metric>> |{logstash-ref}/configuration-file-structure.html#boolean[boolean]|No -| <<{version}-plugins-{type}s-{plugin}-id>> |{logstash-ref}/configuration-file-structure.html#string[string]|No -| <<{version}-plugins-{type}s-{plugin}-periodic_flush>> |{logstash-ref}/configuration-file-structure.html#boolean[boolean]|No -| <<{version}-plugins-{type}s-{plugin}-remove_field>> |{logstash-ref}/configuration-file-structure.html#array[array]|No -| <<{version}-plugins-{type}s-{plugin}-remove_tag>> |{logstash-ref}/configuration-file-structure.html#array[array]|No -|======================================================================= -endif::[] - -ifeval::["{versioned_docs}"!="true"] -[id="plugins-{type}s-{plugin}-add_field"] -endif::[] -ifeval::["{versioned_docs}"=="true"] -[id="{version}-plugins-{type}s-{plugin}-add_field"] -endif::[] -===== `add_field` - - * Value type is {logstash-ref}/configuration-file-structure.html#hash[hash] - * Default value is `{}` - -If this filter is successful, add any arbitrary fields to this event. -Field names can be dynamic and include parts of the event using the `%{field}`. - -Example: - -["source","json",subs="attributes"] - filter { - {plugin} { - add_field => { "foo_%\{somefield\}" => "Hello world, from %\{host\}" } - } - } - -["source","json",subs="attributes"] - # You can also add multiple fields at once: - filter { - {plugin} { - add_field => { - "foo_%\{somefield\}" => "Hello world, from %\{host\}" - "new_field" => "new_static_value" - } - } - } - -If the event has field `"somefield" == "hello"` this filter, on success, -would add field `foo_hello` if it is present, with the -value above and the `%{host}` piece replaced with that value from the -event. The second example would also add a hardcoded field. - -ifeval::["{versioned_docs}"!="true"] -[id="plugins-{type}s-{plugin}-add_tag"] -endif::[] -ifeval::["{versioned_docs}"=="true"] -[id="{version}-plugins-{type}s-{plugin}-add_tag"] -endif::[] -===== `add_tag` - - * Value type is {logstash-ref}/configuration-file-structure.html#array[array] - * Default value is `[]` - -If this filter is successful, add arbitrary tags to the event. -Tags can be dynamic and include parts of the event using the `%{field}` -syntax. - -Example: - -["source","json",subs="attributes"] - filter { - {plugin} { - add_tag => [ "foo_%\{somefield\}" ] - } - } - -["source","json",subs="attributes"] - # You can also add multiple tags at once: - filter { - {plugin} { - add_tag => [ "foo_%\{somefield\}", "taggedy_tag"] - } - } - -If the event has field `"somefield" == "hello"` this filter, on success, -would add a tag `foo_hello` (and the second example would of course add a `taggedy_tag` tag). - -ifeval::["{versioned_docs}"!="true"] -[id="plugins-{type}s-{plugin}-enable_metric"] -endif::[] -ifeval::["{versioned_docs}"=="true"] -[id="{version}-plugins-{type}s-{plugin}-enable_metric"] -endif::[] -===== `enable_metric` - - * Value type is {logstash-ref}/configuration-file-structure.html#boolean[boolean] - * Default value is `true` - -Disable or enable metric logging for this specific plugin instance. -By default we record all the metrics we can, but you can disable metrics collection -for a specific plugin. - -ifeval::["{versioned_docs}"!="true"] -[id="plugins-{type}s-{plugin}-id"] -endif::[] -ifeval::["{versioned_docs}"=="true"] -[id="{version}-plugins-{type}s-{plugin}-id"] -endif::[] -===== `id` - - * Value type is {logstash-ref}/configuration-file-structure.html#string[string] - * There is no default value for this setting. - -Add a unique `ID` to the plugin configuration. If no ID is specified, Logstash will generate one. -It is strongly recommended to set this ID in your configuration. This is particularly useful -when you have two or more plugins of the same type, for example, if you have 2 {plugin} filters. -Adding a named ID in this case will help in monitoring Logstash when using the monitoring APIs. - - -["source","json",subs="attributes"] - filter { - {plugin} { - id => "ABC" - } - } - -NOTE: Variable substitution in the `id` field only supports environment variables - and does not support the use of values from the secret store. - -ifeval::["{versioned_docs}"!="true"] -[id="plugins-{type}s-{plugin}-periodic_flush"] -endif::[] -ifeval::["{versioned_docs}"=="true"] -[id="{version}-plugins-{type}s-{plugin}-periodic_flush"] -endif::[] -===== `periodic_flush` - - * Value type is {logstash-ref}/configuration-file-structure.html#boolean[boolean] - * Default value is `false` - -Call the filter flush method at regular interval. -Optional. - -ifeval::["{versioned_docs}"!="true"] -[id="plugins-{type}s-{plugin}-remove_field"] -endif::[] -ifeval::["{versioned_docs}"=="true"] -[id="{version}-plugins-{type}s-{plugin}-remove_field"] -endif::[] -===== `remove_field` - - * Value type is {logstash-ref}/configuration-file-structure.html#array[array] - * Default value is `[]` - -If this filter is successful, remove arbitrary fields from this event. -Fields names can be dynamic and include parts of the event using the %{field} -Example: - -["source","json",subs="attributes"] - filter { - {plugin} { - remove_field => [ "foo_%\{somefield\}" ] - } - } - -["source","json",subs="attributes"] - # You can also remove multiple fields at once: - filter { - {plugin} { - remove_field => [ "foo_%\{somefield\}", "my_extraneous_field" ] - } - } - -If the event has field `"somefield" == "hello"` this filter, on success, -would remove the field with name `foo_hello` if it is present. The second -example would remove an additional, non-dynamic field. - -ifeval::["{versioned_docs}"!="true"] -[id="plugins-{type}s-{plugin}-remove_tag"] -endif::[] -ifeval::["{versioned_docs}"=="true"] -[id="{version}-plugins-{type}s-{plugin}-remove_tag"] -endif::[] -===== `remove_tag` - - * Value type is {logstash-ref}/configuration-file-structure.html#array[array] - * Default value is `[]` - -If this filter is successful, remove arbitrary tags from the event. -Tags can be dynamic and include parts of the event using the `%{field}` -syntax. - -Example: - -["source","json",subs="attributes"] - filter { - {plugin} { - remove_tag => [ "foo_%\{somefield\}" ] - } - } - -["source","json",subs="attributes"] - # You can also remove multiple tags at once: - filter { - {plugin} { - remove_tag => [ "foo_%\{somefield\}", "sad_unwanted_tag"] - } - } - -If the event has field `"somefield" == "hello"` this filter, on success, -would remove the tag `foo_hello` if it is present. The second example -would remove a sad, unwanted tag as well. diff --git a/docs/include/input.asciidoc b/docs/include/input.asciidoc deleted file mode 100644 index 5ef643aac..000000000 --- a/docs/include/input.asciidoc +++ /dev/null @@ -1,172 +0,0 @@ -==== Common options - -// Contributors: You must conditionally code all internal links and IDs in this -// file to make the common files work in both the LS Reference and the versioned -// plugin docs - -These configuration options are supported by all input plugins: - -[cols="<,<,<",options="header",] -ifeval::["{versioned_docs}"!="true"] -|======================================================================= -|Setting |Input type|Required -| <> |{logstash-ref}/configuration-file-structure.html#hash[hash]|No -ifndef::no_codec[] -| <> |{logstash-ref}/configuration-file-structure.html#codec[codec]|No -endif::no_codec[] -| <> |{logstash-ref}/configuration-file-structure.html#boolean[boolean]|No -| <> |{logstash-ref}/configuration-file-structure.html#string[string]|No -| <> |{logstash-ref}/configuration-file-structure.html#array[array]|No -| <> |{logstash-ref}/configuration-file-structure.html#string[string]|No -|======================================================================= -endif::[] -ifeval::["{versioned_docs}"=="true"] -|======================================================================= -|Setting |Input type|Required -| <<{version}-plugins-{type}s-{plugin}-add_field>> |{logstash-ref}/configuration-file-structure.html#hash[hash]|No -ifndef::no_codec[] -| <<{version}-plugins-{type}s-{plugin}-codec>> |{logstash-ref}/configuration-file-structure.html#codec[codec]|No -endif::no_codec[] -| <<{version}-plugins-{type}s-{plugin}-enable_metric>> |{logstash-ref}/configuration-file-structure.html#boolean[boolean]|No -| <<{version}-plugins-{type}s-{plugin}-id>> |{logstash-ref}/configuration-file-structure.html#string[string]|No -| <<{version}-plugins-{type}s-{plugin}-tags>> |{logstash-ref}/configuration-file-structure.html#array[array]|No -| <<{version}-plugins-{type}s-{plugin}-type>> |{logstash-ref}/configuration-file-structure.html#string[string]|No -|======================================================================= -endif::[] - - -ifeval::["{versioned_docs}"!="true"] -[id="plugins-{type}s-{plugin}-add_field"] -endif::[] -ifeval::["{versioned_docs}"=="true"] -[id="{version}-plugins-{type}s-{plugin}-add_field"] -endif::[] -===== `add_field` - - * Value type is {logstash-ref}/configuration-file-structure.html#hash[hash] - * Default value is `{}` - -Add a field to an event - -ifndef::no_codec[] -ifeval::["{versioned_docs}"!="true"] -[id="plugins-{type}s-{plugin}-codec"] -endif::[] -ifeval::["{versioned_docs}"=="true"] -[id="{version}-plugins-{type}s-{plugin}-codec"] -endif::[] -===== `codec` - - * Value type is {logstash-ref}/configuration-file-structure.html#codec[codec] -ifdef::default_codec[] - * Default value is +"{default_codec}"+ -endif::[] -ifndef::default_codec[] - * Default value is `"plain"` -endif::[] - -The codec used for input data. Input codecs are a convenient method for decoding your data before it enters the input, without needing a separate filter in your Logstash pipeline. -endif::no_codec[] - - -ifeval::["{versioned_docs}"!="true"] -[id="plugins-{type}s-{plugin}-enable_metric"] -endif::[] -ifeval::["{versioned_docs}"=="true"] -[id="{version}-plugins-{type}s-{plugin}-enable_metric"] -endif::[] -===== `enable_metric` - - * Value type is {logstash-ref}/configuration-file-structure.html#boolean[boolean] - * Default value is `true` - -Disable or enable metric logging for this specific plugin instance -by default we record all the metrics we can, but you can disable metrics collection -for a specific plugin. - -ifeval::["{versioned_docs}"!="true"] -[id="plugins-{type}s-{plugin}-id"] -endif::[] -ifeval::["{versioned_docs}"=="true"] -[id="{version}-plugins-{type}s-{plugin}-id"] -endif::[] -===== `id` - - * Value type is {logstash-ref}/configuration-file-structure.html#string[string] - * There is no default value for this setting. - -Add a unique `ID` to the plugin configuration. If no ID is specified, Logstash will generate one. -It is strongly recommended to set this ID in your configuration. This is particularly useful -when you have two or more plugins of the same type, for example, if you have 2 {plugin} inputs. -Adding a named ID in this case will help in monitoring Logstash when using the monitoring APIs. - -["source","json",subs="attributes"] ---------------------------------------------------------------------------------------------------- -input { - {plugin} { - id => "my_plugin_id" - } -} ---------------------------------------------------------------------------------------------------- - -NOTE: Variable substitution in the `id` field only supports environment variables - and does not support the use of values from the secret store. - -ifeval::["{versioned_docs}"!="true"] -[id="plugins-{type}s-{plugin}-tags"] -endif::[] -ifeval::["{versioned_docs}"=="true"] -[id="{version}-plugins-{type}s-{plugin}-tags"] -endif::[] -===== `tags` - - * Value type is {logstash-ref}/configuration-file-structure.html#array[array] - * There is no default value for this setting. - -Add any number of arbitrary tags to your event. - -This can help with processing later. - -ifeval::["{versioned_docs}"!="true"] -[id="plugins-{type}s-{plugin}-type"] -endif::[] -ifeval::["{versioned_docs}"=="true"] -[id="{version}-plugins-{type}s-{plugin}-type"] -endif::[] -===== `type` - - * Value type is {logstash-ref}/configuration-file-structure.html#string[string] - * There is no default value for this setting. - -Add a `type` field to all events handled by this input. - -Types are used mainly for filter activation. - -The type is stored as part of the event itself, so you can -also use the type to search for it in Kibana. - -If you try to set a type on an event that already has one (for -example when you send an event from a shipper to an indexer) then -a new input will not override the existing type. A type set at -the shipper stays with that event for its life even -when sent to another Logstash server. - -ifeval::["{type}"=="input"] -ifeval::["{plugin}"=="beats"] - -ifeval::["{versioned_docs}"!="true"] -NOTE: The Beats shipper automatically sets the `type` field on the event. -You cannot override this setting in the Logstash config. If you specify -a setting for the <> config option in -Logstash, it is ignored. -endif::[] -ifeval::["{versioned_docs}"=="true"] -NOTE: The Beats shipper automatically sets the `type` field on the event. -You cannot override this setting in the Logstash config. If you specify -a setting for the <<{version}-plugins-inputs-beats-type,`type`>> config option in -Logstash, it is ignored. -endif::[] - -endif::[] -endif::[] - diff --git a/docs/include/output.asciidoc b/docs/include/output.asciidoc deleted file mode 100644 index 8e9453c4e..000000000 --- a/docs/include/output.asciidoc +++ /dev/null @@ -1,94 +0,0 @@ -==== Common options - -// Contributors: You must conditionally code all internal links and IDs in this -// file to make the common files work in both the LS Reference and the versioned -// plugin docs - -These configuration options are supported by all output plugins: - -ifeval::["{versioned_docs}"!="true"] -[cols="<,<,<",options="header",] -|======================================================================= -|Setting |Input type|Required -ifndef::no_codec[] -| <> |{logstash-ref}/configuration-file-structure.html#codec[codec]|No -endif::no_codec[] -| <> |{logstash-ref}/configuration-file-structure.html#boolean[boolean]|No -| <> |{logstash-ref}/configuration-file-structure.html#string[string]|No -|======================================================================= -endif::[] -ifeval::["{versioned_docs}"=="true"] -[cols="<,<,<",options="header",] -|======================================================================= -|Setting |Input type|Required -ifndef::no_codec[] -| <<{version}-plugins-{type}s-{plugin}-codec>> |{logstash-ref}/configuration-file-structure.html#codec[codec]|No -endif::no_codec[] -| <<{version}-plugins-{type}s-{plugin}-enable_metric>> |{logstash-ref}/configuration-file-structure.html#boolean[boolean]|No -| <<{version}-plugins-{type}s-{plugin}-id>> |{logstash-ref}/configuration-file-structure.html#string[string]|No -|======================================================================= -endif::[] - -ifndef::no_codec[] -ifeval::["{versioned_docs}"!="true"] -[id="plugins-{type}s-{plugin}-codec"] -endif::[] -ifeval::["{versioned_docs}"=="true"] -[id="{version}-plugins-{type}s-{plugin}-codec"] -endif::[] -===== `codec` - - * Value type is {logstash-ref}/configuration-file-structure.html#codec[codec] -ifdef::default_codec[] - * Default value is +"{default_codec}"+ -endif::[] -ifndef::default_codec[] - * Default value is `"plain"` -endif::[] - -The codec used for output data. Output codecs are a convenient method for encoding your data before it leaves the output without needing a separate filter in your Logstash pipeline. -endif::no_codec[] - -ifeval::["{versioned_docs}"!="true"] -[id="plugins-{type}s-{plugin}-enable_metric"] -endif::[] -ifeval::["{versioned_docs}"=="true"] -[id="{version}-plugins-{type}s-{plugin}-enable_metric"] -endif::[] -===== `enable_metric` - - * Value type is {logstash-ref}/configuration-file-structure.html#boolean[boolean] - * Default value is `true` - -Disable or enable metric logging for this specific plugin instance. -By default we record all the metrics we can, but you can disable metrics collection -for a specific plugin. - -ifeval::["{versioned_docs}"!="true"] -[id="plugins-{type}s-{plugin}-id"] -endif::[] -ifeval::["{versioned_docs}"=="true"] -[id="{version}-plugins-{type}s-{plugin}-id"] -endif::[] -===== `id` - - * Value type is {logstash-ref}/configuration-file-structure.html#string[string] - * There is no default value for this setting. - -Add a unique `ID` to the plugin configuration. If no ID is specified, Logstash will generate one. -It is strongly recommended to set this ID in your configuration. This is particularly useful -when you have two or more plugins of the same type. For example, if you have 2 {plugin} outputs. -Adding a named ID in this case will help in monitoring Logstash when using the monitoring APIs. - -["source","json",subs="attributes"] ---------------------------------------------------------------------------------------------------- -output { - {plugin} { - id => "my_plugin_id" - } -} ---------------------------------------------------------------------------------------------------- - -NOTE: Variable substitution in the `id` field only supports environment variables - and does not support the use of values from the secret store. - diff --git a/docs/include/plugin_header-core.asciidoc b/docs/include/plugin_header-core.asciidoc deleted file mode 100644 index eec4d5901..000000000 --- a/docs/include/plugin_header-core.asciidoc +++ /dev/null @@ -1,14 +0,0 @@ -[subs="attributes"] -++++ -{plugin} -++++ - -*{ls} Core Plugin.* The {plugin} {type} plugin cannot be -installed or uninstalled independently of {ls}. - -==== Getting help - -For questions about the plugin, open a topic in the -http://discuss.elastic.co[Discuss] forums. For bugs or feature requests, open an -issue in https://github.com/logstash[Github]. - diff --git a/docs/include/plugin_header-integration.asciidoc b/docs/include/plugin_header-integration.asciidoc deleted file mode 100644 index 525f84181..000000000 --- a/docs/include/plugin_header-integration.asciidoc +++ /dev/null @@ -1,19 +0,0 @@ -[subs="attributes"] -++++ -{plugin} -++++ - -* A component of the <> -* Integration version: {version} -* Released on: {release_date} -* {changelog_url}[Changelog] - -For other versions, see the -{lsplugindocs}/{type}-{plugin}-index.html[Versioned plugin docs]. - -==== Getting help - -For questions about the plugin, open a topic in the http://discuss.elastic.co[Discuss] forums. -For bugs or feature requests, open an issue in https://github.com/logstash-plugins/logstash-integration-{integration}[Github]. -For the list of Elastic supported plugins, please consult the https://www.elastic.co/support/matrix#logstash_plugins[Elastic Support Matrix]. - diff --git a/docs/include/plugin_header.asciidoc b/docs/include/plugin_header.asciidoc deleted file mode 100644 index c8a169810..000000000 --- a/docs/include/plugin_header.asciidoc +++ /dev/null @@ -1,25 +0,0 @@ -[subs="attributes"] -++++ -{plugin} -++++ - -* Plugin version: {version} -* Released on: {release_date} -* {changelog_url}[Changelog] - -For other versions, see the -{lsplugindocs}/{type}-{plugin}-index.html[Versioned plugin docs]. - -ifeval::["{default_plugin}"=="0"] - -==== Installation - -For plugins not bundled by default, it is easy to install by running +bin/logstash-plugin install logstash-{type}-{plugin}+. See {logstash-ref}/working-with-plugins.html[Working with plugins] for more details. - -endif::[] - -==== Getting help - -For questions about the plugin, open a topic in the http://discuss.elastic.co[Discuss] forums. For bugs or feature requests, open an issue in https://github.com/logstash-plugins/logstash-{type}-{plugin}[Github]. -For the list of Elastic supported plugins, please consult the https://www.elastic.co/support/matrix#logstash_plugins[Elastic Support Matrix]. - diff --git a/docs/include/version-list-intro.asciidoc b/docs/include/version-list-intro.asciidoc deleted file mode 100644 index c396d201c..000000000 --- a/docs/include/version-list-intro.asciidoc +++ /dev/null @@ -1,14 +0,0 @@ -[id="{type}-{plugin}-index"] - -== Versioned {plugin} {type} plugin docs -[subs="attributes"] -++++ -{plugin} -++++ - -This page lists all available versions of the documentation for this plugin. -To see which version of the plugin you have installed, run `bin/logstash-plugin -list --verbose`. - -NOTE: Versioned plugin documentation is not available for plugins released prior -to Logstash 6.0. diff --git a/docs/index.asciidoc b/docs/index.asciidoc deleted file mode 100644 index cc7ce9da6..000000000 --- a/docs/index.asciidoc +++ /dev/null @@ -1,238 +0,0 @@ -[[logstash-reference]] -= Logstash Reference - -include::{docs-root}/shared/versions/stack/{source_branch}.asciidoc[] -include::{docs-root}/shared/attributes.asciidoc[] -include::./include/attributes-ls.asciidoc[] -include::./include/attributes-lsplugins.asciidoc[] - -:include-xpack: true -:lang: en -:xls-repo-dir: {docdir}/../x-pack/docs/{lang} -:log-repo-dir: {docdir} -:plugins-repo-dir: {docdir}/../../logstash-docs/docs -:docker-repo: docker.elastic.co/logstash/logstash -:docker-image: {docker-repo}:{logstash_version} - -:versioned_docs: false - -:jdk: 1.8.0 -:lsissue: https://github.com/elastic/logstash/issues -:lsplugindocs: https://www.elastic.co/guide/en/logstash-versioned-plugins/current -:tab-widget-dir: {docdir}/static/tab-widgets - - -[[introduction]] -== Logstash Introduction - -Logstash is an open source data collection engine with real-time pipelining capabilities. Logstash can dynamically -unify data from disparate sources and normalize the data into destinations of your choice. Cleanse and democratize all -your data for diverse advanced downstream analytics and visualization use cases. - -While Logstash originally drove innovation in log collection, its capabilities extend well beyond that use case. Any -type of event can be enriched and transformed with a broad array of input, filter, and output plugins, with many -native codecs further simplifying the ingestion process. Logstash accelerates your insights by harnessing a greater -volume and variety of data. - - -[serverless] -.Logstash to {serverless-full} -**** -You'll use the {ls} <> to send data to {serverless-full}. -Note these differences between {es-serverless} and both {ess} and self-managed {es}: - -* Use *API keys* to access {serverless-full} from {ls}. -Any user-based security settings in your in your <> configuration are ignored and may cause errors. -* {serverless-full} uses *data streams* and {ref}/data-stream-lifecycle.html[{dlm} ({dlm-init})] instead of {ilm} ({ilm-init}). -Any {ilm-init} settings in your <> configuration are ignored and may cause errors. -* *{ls} monitoring* is available through the https://github.com/elastic/integrations/blob/main/packages/logstash/_dev/build/docs/README.md[{ls} Integration] in {serverless-docs}/observability/what-is-observability-serverless[Elastic Observability] on {serverless-full}. - - -.Known issue for {ls} to {es-serverless}. - -The logstash-output-elasticsearch `hosts` setting defaults to port :9200. Set the value to port :443 instead. -**** - - -// The pass blocks here point to the correct repository for the edit links in the guide. - -// Introduction - -// Getting Started with Logstash -include::static/getting-started-with-logstash.asciidoc[] - -// Advanced LS Pipelines -include::static/advanced-pipeline.asciidoc[] - -// Processing Pipeline -include::static/life-of-an-event.asciidoc[] - -// Elastic Common Schema (ECS) -include::static/ecs-compatibility.asciidoc[] - -// Processing details -include::static/processing-info.asciidoc[] - -// Logstash setup -include::static/setting-up-logstash.asciidoc[] - -include::static/settings-file.asciidoc[] - -include::static/keystore.asciidoc[] - -include::static/running-logstash-command-line.asciidoc[] - -include::static/running-logstash.asciidoc[] - -include::static/docker.asciidoc[] - -include::static/running-logstash-kubernetes.asciidoc[] - -include::static/running-logstash-windows.asciidoc[] - -include::static/logging.asciidoc[] - -include::static/shutdown.asciidoc[] - -// Upgrading Logstash -include::static/upgrading.asciidoc[] - -// Configuring pipelines -include::static/pipeline-configuration.asciidoc[] - -// Security -include::static/security/logstash.asciidoc[] - -// Advanced Logstash Configuration -include::static/configuration-advanced.asciidoc[] - -include::static/multiple-pipelines.asciidoc[] - -include::static/pipeline-pipeline-config.asciidoc[] - -include::static/reloading-config.asciidoc[] - -include::static/managing-multiline-events.asciidoc[] - -include::static/glob-support.asciidoc[] - -include::static/field-reference.asciidoc[] - -//The `field-reference.asciidoc` file (included above) contains a -//`role="exclude"` attribute to pull in the topic and make it linkable in the LS -//Ref, but not appear in the main TOC. The `exclude`attribute was carrying -//forward for all subsequent topics under the `configuration.asciidoc` heading. -//This include should remain after includes for all other topics under the -//`Advanced Logstash Configuration` heading. - -// Logstash-to-Logstash -include::static/ls-ls-config.asciidoc[] - -// Centralized configuration managements -include::static/config-management.asciidoc[] - -include::static/management/configuring-centralized-pipelines.asciidoc[] - -// EA Integrations to Logstash -// (Planting near module content for now. Will likely move it up in info architecture.) -include::static/ea-integrations.asciidoc[] - - -// Working with Filebeat Modules -include::static/filebeat-modules.asciidoc[] - -// Working with Winlogbeat Modules -include::static/winlogbeat-modules.asciidoc[] - -// Data resiliency -include::static/resiliency.asciidoc[] - -include::static/mem-queue.asciidoc[] - -include::static/persistent-queues.asciidoc[] - -include::static/dead-letter-queues.asciidoc[] - -// Transforming Data -include::static/transforming-data.asciidoc[] - -// Deploying & Scaling -include::static/deploying.asciidoc[] - -// GeoIP Database Management -include::static/geoip-database-management.asciidoc[] - -// Troubleshooting performance -include::static/performance-checklist.asciidoc[] - -// Monitoring -include::static/monitoring/monitoring-ea-intro.asciidoc[] - -include::static/monitoring/monitoring-overview.asciidoc[] - -include::static/monitoring/monitoring.asciidoc[] - -// Working with Plugins -include::static/plugin-manager.asciidoc[] - -// These files do their own pass blocks - -include::{plugins-repo-dir}/plugins/integrations.asciidoc[] - -include::{plugins-repo-dir}/plugins/inputs.asciidoc[] - -include::{plugins-repo-dir}/plugins/outputs.asciidoc[] - -include::{plugins-repo-dir}/plugins/filters.asciidoc[] - -include::{plugins-repo-dir}/plugins/codecs.asciidoc[] - -// FAQ and Troubleshooting -:edit_url!: -include::static/best-practice.asciidoc[] - -include::static/config-details.asciidoc[] - -include::static/troubleshoot/troubleshooting.asciidoc[] - -// Contributing to Logstash -:edit_url: -include::static/contributing-to-logstash.asciidoc[] - -include::static/input.asciidoc[] - -include::static/codec.asciidoc[] - -include::static/filter.asciidoc[] - -include::static/output.asciidoc[] - -// Logstash Community Maintainer Guide -include::static/maintainer-guide.asciidoc[] - -// Plugin doc guidelines -include::static/doc-for-plugin.asciidoc[] - -// Submitting a Plugin -include::static/submitting-a-plugin.asciidoc[] - -include::static/listing-a-plugin.asciidoc[] - -include::static/contributing-patch.asciidoc[] - -include::static/contribute-core.asciidoc[] - -// Contributing to Logstash - JAVA EDITION -:edit_url: -include::static/contributing-java-plugin.asciidoc[] - -// Breaking Changes -include::static/breaking-changes.asciidoc[] - -// Release Notes -include::static/releasenotes.asciidoc[] - -:edit_url: -include::static/redirects.asciidoc[] - -:edit_url!: diff --git a/docs/index.x.asciidoc b/docs/index.x.asciidoc deleted file mode 100644 index 35204eef5..000000000 --- a/docs/index.x.asciidoc +++ /dev/null @@ -1 +0,0 @@ -include::index.asciidoc[] diff --git a/docs/reference/advanced-logstash-configurations.md b/docs/reference/advanced-logstash-configurations.md new file mode 100644 index 000000000..13e46133c --- /dev/null +++ b/docs/reference/advanced-logstash-configurations.md @@ -0,0 +1,14 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/configuration-advanced.html +--- + +# Advanced Logstash configurations [configuration-advanced] + +You can take {{ls}} beyond basic configuration to handle more advanced requirements, such as multiple pipelines, communication between {{ls}} pipelines, and multiple line events. + + + + + + diff --git a/docs/reference/advanced-pipeline.md b/docs/reference/advanced-pipeline.md new file mode 100644 index 000000000..c9ae6ec10 --- /dev/null +++ b/docs/reference/advanced-pipeline.md @@ -0,0 +1,612 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/advanced-pipeline.html +--- + +# Parsing Logs with Logstash [advanced-pipeline] + +In [Stashing Your First Event](/reference/first-event.md), you created a basic Logstash pipeline to test your Logstash setup. In the real world, a Logstash pipeline is a bit more complex: it typically has one or more input, filter, and output plugins. + +In this section, you create a Logstash pipeline that uses Filebeat to take Apache web logs as input, parses those logs to create specific, named fields from the logs, and writes the parsed data to an Elasticsearch cluster. Rather than defining the pipeline configuration at the command line, you’ll define the pipeline in a config file. + +To get started, go [here](https://download.elastic.co/demos/logstash/gettingstarted/logstash-tutorial.log.gz) to download the sample data set used in this example. Unpack the file. + +## Configuring Filebeat to Send Log Lines to Logstash [configuring-filebeat] + +Before you create the Logstash pipeline, you’ll configure Filebeat to send log lines to Logstash. The [Filebeat](https://github.com/elastic/beats/tree/main/filebeat) client is a lightweight, resource-friendly tool that collects logs from files on the server and forwards these logs to your Logstash instance for processing. Filebeat is designed for reliability and low latency. Filebeat has a light resource footprint on the host machine, and the [`Beats input`](/reference/plugins-inputs-beats.md) plugin minimizes the resource demands on the Logstash instance. + +::::{note} +In a typical use case, Filebeat runs on a separate machine from the machine running your Logstash instance. For the purposes of this tutorial, Logstash and Filebeat are running on the same machine. +:::: + + +The default Logstash installation includes the [`Beats input`](/reference/plugins-inputs-beats.md) plugin. The Beats input plugin enables Logstash to receive events from the Elastic Beats framework, which means that any Beat written to work with the Beats framework, such as Packetbeat and Metricbeat, can also send event data to Logstash. + +To install Filebeat on your data source machine, download the appropriate package from the Filebeat [product page](https://www.elastic.co/downloads/beats/filebeat). You can also refer to [Filebeat quick start](beats://reference/filebeat/filebeat-installation-configuration.md) for additional installation instructions. + +After installing Filebeat, you need to configure it. Open the `filebeat.yml` file located in your Filebeat installation directory, and replace the contents with the following lines. Make sure `paths` points to the example Apache log file, `logstash-tutorial.log`, that you downloaded earlier: + +```yaml +filebeat.inputs: +- type: log + paths: + - /path/to/file/logstash-tutorial.log <1> +output.logstash: + hosts: ["localhost:5044"] +``` + +1. Absolute path to the file or files that Filebeat processes. + + +Save your changes. + +To keep the configuration simple, you won’t specify TLS/SSL settings as you would in a real world scenario. + +At the data source machine, run Filebeat with the following command: + +```shell +sudo ./filebeat -e -c filebeat.yml -d "publish" +``` + +::::{note} +If you run Filebeat as root, you need to change ownership of the configuration file (see [Config File Ownership and Permissions](beats://reference/libbeat/config-file-permissions.md) in the *Beats Platform Reference*). +:::: + + +Filebeat will attempt to connect on port 5044. Until Logstash starts with an active Beats plugin, there won’t be any answer on that port, so any messages you see regarding failure to connect on that port are normal for now. + + +## Configuring Logstash for Filebeat Input [_configuring_logstash_for_filebeat_input] + +Next, you create a Logstash configuration pipeline that uses the Beats input plugin to receive events from Beats. + +The following text represents the skeleton of a configuration pipeline: + +```json +# The # character at the beginning of a line indicates a comment. Use +# comments to describe your configuration. +input { +} +# The filter part of this file is commented out to indicate that it is +# optional. +# filter { +# +# } +output { +} +``` + +This skeleton is non-functional, because the input and output sections don’t have any valid options defined. + +To get started, copy and paste the skeleton configuration pipeline into a file named `first-pipeline.conf` in your home Logstash directory. + +Next, configure your Logstash instance to use the Beats input plugin by adding the following lines to the `input` section of the `first-pipeline.conf` file: + +```json + beats { + port => "5044" + } +``` + +You’ll configure Logstash to write to Elasticsearch later. For now, you can add the following line to the `output` section so that the output is printed to stdout when you run Logstash: + +```json + stdout { codec => rubydebug } +``` + +When you’re done, the contents of `first-pipeline.conf` should look like this: + +```json +input { + beats { + port => "5044" + } +} +# The filter part of this file is commented out to indicate that it is +# optional. +# filter { +# +# } +output { + stdout { codec => rubydebug } +} +``` + +To verify your configuration, run the following command: + +```shell +bin/logstash -f first-pipeline.conf --config.test_and_exit +``` + +The `--config.test_and_exit` option parses your configuration file and reports any errors. + +If the configuration file passes the configuration test, start Logstash with the following command: + +```shell +bin/logstash -f first-pipeline.conf --config.reload.automatic +``` + +The `--config.reload.automatic` option enables automatic config reloading so that you don’t have to stop and restart Logstash every time you modify the configuration file. + +As Logstash starts up, you might see one or more warning messages about Logstash ignoring the `pipelines.yml` file. You can safely ignore this warning. The `pipelines.yml` file is used for running [multiple pipelines](/reference/multiple-pipelines.md) in a single Logstash instance. For the examples shown here, you are running a single pipeline. + +If your pipeline is working correctly, you should see a series of events like the following written to the console: + +```json +{ + "@timestamp" => 2017-11-09T01:44:20.071Z, + "offset" => 325, + "@version" => "1", + "beat" => { + "name" => "My-MacBook-Pro.local", + "hostname" => "My-MacBook-Pro.local", + "version" => "6.0.0" + }, + "host" => "My-MacBook-Pro.local", + "prospector" => { + "type" => "log" + }, + "input" => { + "type" => "log" + }, + "source" => "/path/to/file/logstash-tutorial.log", + "message" => "83.149.9.216 - - [04/Jan/2015:05:13:42 +0000] \"GET /presentations/logstash-monitorama-2013/images/kibana-search.png HTTP/1.1\" 200 203023 \"http://semicomplete.com/presentations/logstash-monitorama-2013/\" \"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36\"", + "tags" => [ + [0] "beats_input_codec_plain_applied" + ] +} +... +``` + + +### Parsing Web Logs with the Grok Filter Plugin [configuring-grok-filter] + +Now you have a working pipeline that reads log lines from Filebeat. However you’ll notice that the format of the log messages is not ideal. You want to parse the log messages to create specific, named fields from the logs. To do this, you’ll use the `grok` filter plugin. + +The [`grok`](/reference/plugins-filters-grok.md) filter plugin is one of several plugins that are available by default in Logstash. For details on how to manage Logstash plugins, see the [reference documentation](/reference/working-with-plugins.md) for the plugin manager. + +The `grok` filter plugin enables you to parse the unstructured log data into something structured and queryable. + +Because the `grok` filter plugin looks for patterns in the incoming log data, configuring the plugin requires you to make decisions about how to identify the patterns that are of interest to your use case. A representative line from the web server log sample looks like this: + +```shell +83.149.9.216 - - [04/Jan/2015:05:13:42 +0000] "GET /presentations/logstash-monitorama-2013/images/kibana-search.png +HTTP/1.1" 200 203023 "http://semicomplete.com/presentations/logstash-monitorama-2013/" "Mozilla/5.0 (Macintosh; Intel +Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36" +``` + +The IP address at the beginning of the line is easy to identify, as is the timestamp in brackets. To parse the data, you can use the `%{{COMBINEDAPACHELOG}}` grok pattern, which structures lines from the Apache log using the following schema: + +**Information** +: **Field Name** + +IP Address +: `clientip` + +User ID +: `ident` + +User Authentication +: `auth` + +timestamp +: `timestamp` + +HTTP Verb +: `verb` + +Request body +: `request` + +HTTP Version +: `httpversion` + +HTTP Status Code +: `response` + +Bytes served +: `bytes` + +Referrer URL +: `referrer` + +User agent +: `agent` + +::::{tip} +If you need help building grok patterns, try out the [Grok Debugger](docs-content://explore-analyze/query-filter/tools/grok-debugger.md). The Grok Debugger is an {{xpack}} feature under the Basic License and is therefore **free to use**. +:::: + + +Edit the `first-pipeline.conf` file and replace the entire `filter` section with the following text: + +```json +filter { + grok { + match => { "message" => "%{COMBINEDAPACHELOG}"} + } +} +``` + +When you’re done, the contents of `first-pipeline.conf` should look like this: + +```json +input { + beats { + port => "5044" + } +} +filter { + grok { + match => { "message" => "%{COMBINEDAPACHELOG}"} + } +} +output { + stdout { codec => rubydebug } +} +``` + +Save your changes. Because you’ve enabled automatic config reloading, you don’t have to restart Logstash to pick up your changes. However, you do need to force Filebeat to read the log file from scratch. To do this, go to the terminal window where Filebeat is running and press Ctrl+C to shut down Filebeat. Then delete the Filebeat registry file. For example, run: + +```shell +sudo rm data/registry +``` + +Since Filebeat stores the state of each file it harvests in the registry, deleting the registry file forces Filebeat to read all the files it’s harvesting from scratch. + +Next, restart Filebeat with the following command: + +```shell +sudo ./filebeat -e -c filebeat.yml -d "publish" +``` + +There might be a slight delay before Filebeat begins processing events if it needs to wait for Logstash to reload the config file. + +After Logstash applies the grok pattern, the events will have the following JSON representation: + +```json +{ + "request" => "/presentations/logstash-monitorama-2013/images/kibana-search.png", + "agent" => "\"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36\"", + "offset" => 325, + "auth" => "-", + "ident" => "-", + "verb" => "GET", + "prospector" => { + "type" => "log" + }, + "input" => { + "type" => "log" + }, + "source" => "/path/to/file/logstash-tutorial.log", + "message" => "83.149.9.216 - - [04/Jan/2015:05:13:42 +0000] \"GET /presentations/logstash-monitorama-2013/images/kibana-search.png HTTP/1.1\" 200 203023 \"http://semicomplete.com/presentations/logstash-monitorama-2013/\" \"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36\"", + "tags" => [ + [0] "beats_input_codec_plain_applied" + ], + "referrer" => "\"http://semicomplete.com/presentations/logstash-monitorama-2013/\"", + "@timestamp" => 2017-11-09T02:51:12.416Z, + "response" => "200", + "bytes" => "203023", + "clientip" => "83.149.9.216", + "@version" => "1", + "beat" => { + "name" => "My-MacBook-Pro.local", + "hostname" => "My-MacBook-Pro.local", + "version" => "6.0.0" + }, + "host" => "My-MacBook-Pro.local", + "httpversion" => "1.1", + "timestamp" => "04/Jan/2015:05:13:42 +0000" +} +``` + +Notice that the event includes the original message, but the log message is also broken down into specific fields. + + +### Enhancing Your Data with the Geoip Filter Plugin [configuring-geoip-plugin] + +In addition to parsing log data for better searches, filter plugins can derive supplementary information from existing data. As an example, the [`geoip`](/reference/plugins-filters-geoip.md) plugin looks up IP addresses, derives geographic location information from the addresses, and adds that location information to the logs. + +Configure your Logstash instance to use the `geoip` filter plugin by adding the following lines to the `filter` section of the `first-pipeline.conf` file: + +```json + geoip { + source => "clientip" + } +``` + +The `geoip` plugin configuration requires you to specify the name of the source field that contains the IP address to look up. In this example, the `clientip` field contains the IP address. + +Since filters are evaluated in sequence, make sure that the `geoip` section is after the `grok` section of the configuration file and that both the `grok` and `geoip` sections are nested within the `filter` section. + +When you’re done, the contents of `first-pipeline.conf` should look like this: + +```json +input { + beats { + port => "5044" + } +} + filter { + grok { + match => { "message" => "%{COMBINEDAPACHELOG}"} + } + geoip { + source => "clientip" + } +} +output { + stdout { codec => rubydebug } +} +``` + +Save your changes. To force Filebeat to read the log file from scratch, as you did earlier, shut down Filebeat (press Ctrl+C), delete the registry file, and then restart Filebeat with the following command: + +```shell +sudo ./filebeat -e -c filebeat.yml -d "publish" +``` + +Notice that the event now contains geographic location information: + +```json +{ + "request" => "/presentations/logstash-monitorama-2013/images/kibana-search.png", + "agent" => "\"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36\"", + "geoip" => { + "timezone" => "Europe/Moscow", + "ip" => "83.149.9.216", + "latitude" => 55.7485, + "continent_code" => "EU", + "city_name" => "Moscow", + "country_name" => "Russia", + "country_code2" => "RU", + "country_code3" => "RU", + "region_name" => "Moscow", + "location" => { + "lon" => 37.6184, + "lat" => 55.7485 + }, + "postal_code" => "101194", + "region_code" => "MOW", + "longitude" => 37.6184 + }, + ... +``` + + +### Indexing Your Data into Elasticsearch [indexing-parsed-data-into-elasticsearch] + +Now that the web logs are broken down into specific fields, you’re ready to get your data into Elasticsearch. + +::::{tip} +{ess-leadin} +:::: + + +The Logstash pipeline can index the data into an Elasticsearch cluster. Edit the `first-pipeline.conf` file and replace the entire `output` section with the following text: + +```json +output { + elasticsearch { + hosts => [ "localhost:9200" ] + } +} +``` + +With this configuration, Logstash uses http protocol to connect to Elasticsearch. The above example assumes that Logstash and Elasticsearch are running on the same instance. You can specify a remote Elasticsearch instance by using the `hosts` configuration to specify something like `hosts => [ "es-machine:9092" ]`. + +At this point, your `first-pipeline.conf` file has input, filter, and output sections properly configured, and looks something like this: + +```json +input { + beats { + port => "5044" + } +} + filter { + grok { + match => { "message" => "%{COMBINEDAPACHELOG}"} + } + geoip { + source => "clientip" + } +} +output { + elasticsearch { + hosts => [ "localhost:9200" ] + } +} +``` + +Save your changes. To force Filebeat to read the log file from scratch, as you did earlier, shut down Filebeat (press Ctrl+C), delete the registry file, and then restart Filebeat with the following command: + +```shell +sudo ./filebeat -e -c filebeat.yml -d "publish" +``` + + +#### Testing Your Pipeline [testing-initial-pipeline] + +Now that the Logstash pipeline is configured to index the data into an Elasticsearch cluster, you can query Elasticsearch. + +Try a test query to Elasticsearch based on the fields created by the `grok` filter plugin. Replace $DATE with the current date, in YYYY.MM.DD format: + +```shell +curl -XGET 'localhost:9200/logstash-$DATE/_search?pretty&q=response=200' +``` + +::::{note} +The date used in the index name is based on UTC, not the timezone where Logstash is running. If the query returns `index_not_found_exception`, make sure that `logstash-$DATE` reflects the actual name of the index. To see a list of available indexes, use this query: `curl 'localhost:9200/_cat/indices?v'`. +:::: + + +You should get multiple hits back. For example: + +```json +{ + "took": 50, + "timed_out": false, + "_shards": { + "total": 5, + "successful": 5, + "skipped": 0, + "failed": 0 + }, + "hits": { + "total": 98, + "max_score": 2.793642, + "hits": [ + { + "_index": "logstash-2017.11.09", + "_type": "doc", + "_id": "3IzDnl8BW52sR0fx5wdV", + "_score": 2.793642, + "_source": { + "request": "/presentations/logstash-monitorama-2013/images/frontend-response-codes.png", + "agent": """"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36"""", + "geoip": { + "timezone": "Europe/Moscow", + "ip": "83.149.9.216", + "latitude": 55.7485, + "continent_code": "EU", + "city_name": "Moscow", + "country_name": "Russia", + "country_code2": "RU", + "country_code3": "RU", + "region_name": "Moscow", + "location": { + "lon": 37.6184, + "lat": 55.7485 + }, + "postal_code": "101194", + "region_code": "MOW", + "longitude": 37.6184 + }, + "offset": 2932, + "auth": "-", + "ident": "-", + "verb": "GET", + "prospector": { + "type": "log" + }, + "input": { + "type": "log" + }, + "source": "/path/to/file/logstash-tutorial.log", + "message": """83.149.9.216 - - [04/Jan/2015:05:13:45 +0000] "GET /presentations/logstash-monitorama-2013/images/frontend-response-codes.png HTTP/1.1" 200 52878 "http://semicomplete.com/presentations/logstash-monitorama-2013/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36"""", + "tags": [ + "beats_input_codec_plain_applied" + ], + "referrer": """"http://semicomplete.com/presentations/logstash-monitorama-2013/"""", + "@timestamp": "2017-11-09T03:11:35.304Z", + "response": "200", + "bytes": "52878", + "clientip": "83.149.9.216", + "@version": "1", + "beat": { + "name": "My-MacBook-Pro.local", + "hostname": "My-MacBook-Pro.local", + "version": "6.0.0" + }, + "host": "My-MacBook-Pro.local", + "httpversion": "1.1", + "timestamp": "04/Jan/2015:05:13:45 +0000" + } + }, + ... +``` + +Try another search for the geographic information derived from the IP address. Replace $DATE with the current date, in YYYY.MM.DD format: + +```shell +curl -XGET 'localhost:9200/logstash-$DATE/_search?pretty&q=geoip.city_name=Buffalo' +``` + +A few log entries come from Buffalo, so the query produces the following response: + +```json +{ + "took": 9, + "timed_out": false, + "_shards": { + "total": 5, + "successful": 5, + "skipped": 0, + "failed": 0 + }, + "hits": { + "total": 2, + "max_score": 2.6390574, + "hits": [ + { + "_index": "logstash-2017.11.09", + "_type": "doc", + "_id": "L4zDnl8BW52sR0fx5whY", + "_score": 2.6390574, + "_source": { + "request": "/blog/geekery/disabling-battery-in-ubuntu-vms.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+semicomplete%2Fmain+%28semicomplete.com+-+Jordan+Sissel%29", + "agent": """"Tiny Tiny RSS/1.11 (http://tt-rss.org/)"""", + "geoip": { + "timezone": "America/New_York", + "ip": "198.46.149.143", + "latitude": 42.8864, + "continent_code": "NA", + "city_name": "Buffalo", + "country_name": "United States", + "country_code2": "US", + "dma_code": 514, + "country_code3": "US", + "region_name": "New York", + "location": { + "lon": -78.8781, + "lat": 42.8864 + }, + "postal_code": "14202", + "region_code": "NY", + "longitude": -78.8781 + }, + "offset": 22795, + "auth": "-", + "ident": "-", + "verb": "GET", + "prospector": { + "type": "log" + }, + "input": { + "type": "log" + }, + "source": "/path/to/file/logstash-tutorial.log", + "message": """198.46.149.143 - - [04/Jan/2015:05:29:13 +0000] "GET /blog/geekery/disabling-battery-in-ubuntu-vms.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+semicomplete%2Fmain+%28semicomplete.com+-+Jordan+Sissel%29 HTTP/1.1" 200 9316 "-" "Tiny Tiny RSS/1.11 (http://tt-rss.org/)"""", + "tags": [ + "beats_input_codec_plain_applied" + ], + "referrer": """"-"""", + "@timestamp": "2017-11-09T03:11:35.321Z", + "response": "200", + "bytes": "9316", + "clientip": "198.46.149.143", + "@version": "1", + "beat": { + "name": "My-MacBook-Pro.local", + "hostname": "My-MacBook-Pro.local", + "version": "6.0.0" + }, + "host": "My-MacBook-Pro.local", + "httpversion": "1.1", + "timestamp": "04/Jan/2015:05:29:13 +0000" + } + }, + ... +``` + +If you are using Kibana to visualize your data, you can also explore the Filebeat data in Kibana: + +:::{image} ../images/kibana-filebeat-data.png +:alt: Discovering Filebeat data in Kibana +::: + +See the [Filebeat quick start docs](beats://reference/filebeat/filebeat-installation-configuration.md) for info about loading the Kibana index pattern for Filebeat. + +You’ve successfully created a pipeline that uses Filebeat to take Apache web logs as input, parses those logs to create specific, named fields from the logs, and writes the parsed data to an Elasticsearch cluster. Next, you learn how to create a pipeline that uses multiple input and output plugins. + + diff --git a/docs/reference/codec-plugins.md b/docs/reference/codec-plugins.md new file mode 100644 index 000000000..17622dc03 --- /dev/null +++ b/docs/reference/codec-plugins.md @@ -0,0 +1,67 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/codec-plugins.html +--- + +# Codec plugins [codec-plugins] + +A codec plugin changes the data representation of an event. Codecs are essentially stream filters that can operate as part of an input or output. + +The following codec plugins are available below. For a list of Elastic supported plugins, please consult the [Support Matrix](https://www.elastic.co/support/matrix#show_logstash_plugins). + +| | | | +| --- | --- | --- | +| Plugin | Description | Github repository | +| [avro](/reference/plugins-codecs-avro.md) | Reads serialized Avro records as Logstash events | [logstash-codec-avro](https://github.com/logstash-plugins/logstash-codec-avro) | +| [cef](/reference/plugins-codecs-cef.md) | Reads the ArcSight Common Event Format (CEF). | [logstash-codec-cef](https://github.com/logstash-plugins/logstash-codec-cef) | +| [cloudfront](/reference/plugins-codecs-cloudfront.md) | Reads AWS CloudFront reports | [logstash-codec-cloudfront](https://github.com/logstash-plugins/logstash-codec-cloudfront) | +| [cloudtrail](/reference/plugins-codecs-cloudtrail.md) | Reads AWS CloudTrail log files | [logstash-codec-cloudtrail](https://github.com/logstash-plugins/logstash-codec-cloudtrail) | +| [collectd](/reference/plugins-codecs-collectd.md) | Reads events from the `collectd` binary protocol using UDP. | [logstash-codec-collectd](https://github.com/logstash-plugins/logstash-codec-collectd) | +| [csv](/reference/plugins-codecs-csv.md) | Takes CSV data, parses it, and passes it along. | [logstash-codec-csv](https://github.com/logstash-plugins/logstash-codec-csv) | +| [dots](/reference/plugins-codecs-dots.md) | Sends 1 dot per event to `stdout` for performance tracking | [logstash-codec-dots](https://github.com/logstash-plugins/logstash-codec-dots) | +| [edn](/reference/plugins-codecs-edn.md) | Reads EDN format data | [logstash-codec-edn](https://github.com/logstash-plugins/logstash-codec-edn) | +| [edn_lines](/reference/plugins-codecs-edn_lines.md) | Reads newline-delimited EDN format data | [logstash-codec-edn_lines](https://github.com/logstash-plugins/logstash-codec-edn_lines) | +| [es_bulk](/reference/plugins-codecs-es_bulk.md) | Reads the Elasticsearch bulk format into separate events, along with metadata | [logstash-codec-es_bulk](https://github.com/logstash-plugins/logstash-codec-es_bulk) | +| [fluent](/reference/plugins-codecs-fluent.md) | Reads the `fluentd` `msgpack` schema | [logstash-codec-fluent](https://github.com/logstash-plugins/logstash-codec-fluent) | +| [graphite](/reference/plugins-codecs-graphite.md) | Reads `graphite` formatted lines | [logstash-codec-graphite](https://github.com/logstash-plugins/logstash-codec-graphite) | +| [gzip_lines](/reference/plugins-codecs-gzip_lines.md) | Reads `gzip` encoded content | [logstash-codec-gzip_lines](https://github.com/logstash-plugins/logstash-codec-gzip_lines) | +| [jdots](/reference/plugins-codecs-jdots.md) | Renders each processed event as a dot | [core plugin](https://github.com/elastic/logstash/blob/master/logstash-core/src/main/java/org/logstash/plugins/codecs/Dots.java) | +| [java_line](/reference/plugins-codecs-java_line.md) | Encodes and decodes line-oriented text data | [core plugin](https://github.com/elastic/logstash/blob/master/logstash-core/src/main/java/org/logstash/plugins/codecs/Line.java) | +| [java_plain](/reference/plugins-codecs-java_plain.md) | Processes text data with no delimiters between events | [core plugin](https://github.com/elastic/logstash/blob/master/logstash-core/src/main/java/org/logstash/plugins/codecs/Plain.java) | +| [json](/reference/plugins-codecs-json.md) | Reads JSON formatted content, creating one event per element in a JSON array | [logstash-codec-json](https://github.com/logstash-plugins/logstash-codec-json) | +| [json_lines](/reference/plugins-codecs-json_lines.md) | Reads newline-delimited JSON | [logstash-codec-json_lines](https://github.com/logstash-plugins/logstash-codec-json_lines) | +| [line](/reference/plugins-codecs-line.md) | Reads line-oriented text data | [logstash-codec-line](https://github.com/logstash-plugins/logstash-codec-line) | +| [msgpack](/reference/plugins-codecs-msgpack.md) | Reads MessagePack encoded content | [logstash-codec-msgpack](https://github.com/logstash-plugins/logstash-codec-msgpack) | +| [multiline](/reference/plugins-codecs-multiline.md) | Merges multiline messages into a single event | [logstash-codec-multiline](https://github.com/logstash-plugins/logstash-codec-multiline) | +| [netflow](/reference/plugins-codecs-netflow.md) | Reads Netflow v5 and Netflow v9 data | [logstash-codec-netflow](https://github.com/logstash-plugins/logstash-codec-netflow) | +| [nmap](/reference/plugins-codecs-nmap.md) | Reads Nmap data in XML format | [logstash-codec-nmap](https://github.com/logstash-plugins/logstash-codec-nmap) | +| [plain](/reference/plugins-codecs-plain.md) | Reads plaintext with no delimiting between events | [logstash-codec-plain](https://github.com/logstash-plugins/logstash-codec-plain) | +| [protobuf](/reference/plugins-codecs-protobuf.md) | Reads protobuf messages and converts to Logstash Events | [logstash-codec-protobuf](https://github.com/logstash-plugins/logstash-codec-protobuf) | +| [rubydebug](/reference/plugins-codecs-rubydebug.md) | Applies the Ruby Awesome Print library to Logstash events | [logstash-codec-rubydebug](https://github.com/logstash-plugins/logstash-codec-rubydebug) | + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs/static/pipeline-config-exps.asciidoc b/docs/reference/config-examples.md similarity index 64% rename from docs/static/pipeline-config-exps.asciidoc rename to docs/reference/config-examples.md index e13649659..966576d67 100644 --- a/docs/static/pipeline-config-exps.asciidoc +++ b/docs/reference/config-examples.md @@ -1,18 +1,23 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/config-examples.html +--- + +# Logstash configuration examples [config-examples] -[[config-examples]] -=== Logstash configuration examples These examples illustrate how you can configure Logstash to filter events, process Apache logs and syslog messages, and use conditionals to control what events are processed by a filter or output. -TIP: If you need help building grok patterns, try out the -{kibana-ref}/xpack-grokdebugger.html[Grok Debugger]. +::::{tip} +If you need help building grok patterns, try out the [Grok Debugger](docs-content://explore-analyze/query-filter/tools/grok-debugger.md). +:::: -[discrete] -[[filter-example]] -==== Configuring filters -Filters are an in-line processing mechanism that provide the flexibility to slice and dice your data to fit your needs. Let's take a look at some filters in action. The following configuration file sets up the `grok` and `date` filters. -[source,ruby] ----------------------------------- + +## Configuring filters [filter-example] + +Filters are an in-line processing mechanism that provide the flexibility to slice and dice your data to fit your needs. Let’s take a look at some filters in action. The following configuration file sets up the `grok` and `date` filters. + +```ruby input { stdin { } } filter { @@ -28,27 +33,23 @@ output { elasticsearch { hosts => ["localhost:9200"] } stdout { codec => rubydebug } } ----------------------------------- +``` Run Logstash with this configuration: -[source,ruby] ----------------------------------- +```ruby bin/logstash -f logstash-filter.conf ----------------------------------- +``` -Now, paste the following line into your terminal and press Enter so it will be -processed by the stdin input: +Now, paste the following line into your terminal and press Enter so it will be processed by the stdin input: -[source,ruby] ----------------------------------- +```ruby 127.0.0.1 - - [11/Dec/2013:00:01:45 -0800] "GET /xampp/status.php HTTP/1.1" 200 3891 "http://cadenza/xampp/navi.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0" ----------------------------------- +``` You should see something returned to stdout that looks like this: -[source,ruby] ----------------------------------- +```ruby { "message" => "127.0.0.1 - - [11/Dec/2013:00:01:45 -0800] \"GET /xampp/status.php HTTP/1.1\" 200 3891 \"http://cadenza/xampp/navi.php\" \"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0\"", "@timestamp" => "2013-12-11T08:01:45.000Z", @@ -66,18 +67,18 @@ You should see something returned to stdout that looks like this: "referrer" => "\"http://cadenza/xampp/navi.php\"", "agent" => "\"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0\"" } ----------------------------------- +``` -As you can see, Logstash (with help from the `grok` filter) was able to parse the log line (which happens to be in Apache "combined log" format) and break it up into many different discrete bits of information. This is extremely useful once you start querying and analyzing our log data. For example, you'll be able to easily run reports on HTTP response codes, IP addresses, referrers, and so on. There are quite a few grok patterns included with Logstash out-of-the-box, so it's quite likely if you need to parse a common log format, someone has already done the work for you. For more information, see the list of https://github.com/logstash-plugins/logstash-patterns-core/tree/main/patterns[Logstash grok patterns] on GitHub. +As you can see, Logstash (with help from the `grok` filter) was able to parse the log line (which happens to be in Apache "combined log" format) and break it up into many different discrete bits of information. This is extremely useful once you start querying and analyzing our log data. For example, you’ll be able to easily run reports on HTTP response codes, IP addresses, referrers, and so on. There are quite a few grok patterns included with Logstash out-of-the-box, so it’s quite likely if you need to parse a common log format, someone has already done the work for you. For more information, see the list of [Logstash grok patterns](https://github.com/logstash-plugins/logstash-patterns-core/tree/main/patterns) on GitHub. -The other filter used in this example is the `date` filter. This filter parses out a timestamp and uses it as the timestamp for the event (regardless of when you're ingesting the log data). You'll notice that the `@timestamp` field in this example is set to December 11, 2013, even though Logstash is ingesting the event at some point afterwards. This is handy when backfilling logs. It gives you the ability to tell Logstash "use this value as the timestamp for this event". +The other filter used in this example is the `date` filter. This filter parses out a timestamp and uses it as the timestamp for the event (regardless of when you’re ingesting the log data). You’ll notice that the `@timestamp` field in this example is set to December 11, 2013, even though Logstash is ingesting the event at some point afterwards. This is handy when backfilling logs. It gives you the ability to tell Logstash "use this value as the timestamp for this event". -[discrete] -==== Processing Apache logs -Let's do something that's actually *useful*: process apache2 access log files! We are going to read the input from a file on the localhost, and use a <> to process the event according to our needs. First, create a file called something like 'logstash-apache.conf' with the following contents (you can change the log's file path to suit your needs): -[source,js] ----------------------------------- +## Processing Apache logs [_processing_apache_logs] + +Let’s do something that’s actually **useful**: process apache2 access log files! We are going to read the input from a file on the localhost, and use a [conditional](/reference/event-dependent-configuration.md#conditionals) to process the event according to our needs. First, create a file called something like *logstash-apache.conf* with the following contents (you can change the log’s file path to suit your needs): + +```js input { file { path => "/tmp/access_log" @@ -103,48 +104,43 @@ output { } stdout { codec => rubydebug } } - ----------------------------------- +``` Then, create the input file you configured above (in this example, "/tmp/access_log") with the following log entries (or use some from your own webserver): -[source,js] ----------------------------------- +```js 71.141.244.242 - kurt [18/May/2011:01:48:10 -0700] "GET /admin HTTP/1.1" 301 566 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3" 134.39.72.245 - - [18/May/2011:12:40:18 -0700] "GET /favicon.ico HTTP/1.1" 200 1189 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2; .NET4.0C; .NET4.0E)" 98.83.179.51 - - [18/May/2011:19:35:08 -0700] "GET /css/main.css HTTP/1.1" 200 1837 "http://www.safesand.com/information.htm" "Mozilla/5.0 (Windows NT 6.0; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1" ----------------------------------- +``` Now, run Logstash with the -f flag to pass in the configuration file: -[source,js] ----------------------------------- +```js bin/logstash -f logstash-apache.conf ----------------------------------- +``` -Now you should see your apache log data in Elasticsearch! Logstash opened and read the specified input file, processing each event it encountered. Any additional lines logged to this file will also be captured, processed by Logstash as events, and stored in Elasticsearch. As an added bonus, they are stashed with the field "type" set to "apache_access" (this is done by the type => "apache_access" line in the input configuration). +Now you should see your apache log data in Elasticsearch! Logstash opened and read the specified input file, processing each event it encountered. Any additional lines logged to this file will also be captured, processed by Logstash as events, and stored in Elasticsearch. As an added bonus, they are stashed with the field "type" set to "apache_access" (this is done by the type ⇒ "apache_access" line in the input configuration). -In this configuration, Logstash is only watching the apache access_log, but it's easy enough to watch both the access_log and the error_log (actually, any file matching `*log`), by changing one line in the above configuration: +In this configuration, Logstash is only watching the apache access_log, but it’s easy enough to watch both the access_log and the error_log (actually, any file matching `*log`), by changing one line in the above configuration: -[source,js] ----------------------------------- +```js input { file { path => "/tmp/*_log" ... ----------------------------------- +``` -When you restart Logstash, it will process both the error and access logs. However, if you inspect your data (using elasticsearch-kopf, perhaps), you'll see that the access_log is broken up into discrete fields, but the error_log isn't. That's because we used a `grok` filter to match the standard combined apache log format and automatically split the data into separate fields. Wouldn't it be nice *if* we could control how a line was parsed, based on its format? Well, we can... +When you restart Logstash, it will process both the error and access logs. However, if you inspect your data (using elasticsearch-kopf, perhaps), you’ll see that the access_log is broken up into discrete fields, but the error_log isn’t. That’s because we used a `grok` filter to match the standard combined apache log format and automatically split the data into separate fields. Wouldn’t it be nice **if** we could control how a line was parsed, based on its format? Well, we can…​ Note that Logstash did not reprocess the events that were already seen in the access_log file. When reading from a file, Logstash saves its position and only processes new lines as they are added. Neat! -[discrete] -[[using-conditionals]] -==== Using conditionals + +## Using conditionals [using-conditionals] + You use conditionals to control what events are processed by a filter or output. For example, you could label each event according to which file it appeared in (access_log, error_log, and other random files that end with "log"). -[source,ruby] ----------------------------------- +```ruby input { file { path => "/tmp/*_log" @@ -171,9 +167,9 @@ output { elasticsearch { hosts => ["localhost:9200"] } stdout { codec => rubydebug } } ----------------------------------- +``` -This example labels all events using the `type` field, but doesn't actually parse the `error` or `random` files. There are so many types of error logs that how they should be labeled really depends on what logs you're working with. +This example labels all events using the `type` field, but doesn’t actually parse the `error` or `random` files. There are so many types of error logs that how they should be labeled really depends on what logs you’re working with. Similarly, you can use conditionals to direct events to particular outputs. For example, you could: @@ -181,14 +177,9 @@ Similarly, you can use conditionals to direct events to particular outputs. For * record any 4xx status to Elasticsearch * record all status code hits via statsd -To tell nagios about any http event that has a 5xx status code, you -first need to check the value of the `type` field. If it's apache, then you can -check to see if the `status` field contains a 5xx error. If it is, send it to nagios. If it isn't -a 5xx error, check to see if the `status` field contains a 4xx error. If so, send it to Elasticsearch. -Finally, send all apache status codes to statsd no matter what the `status` field contains: +To tell nagios about any http event that has a 5xx status code, you first need to check the value of the `type` field. If it’s apache, then you can check to see if the `status` field contains a 5xx error. If it is, send it to nagios. If it isn’t a 5xx error, check to see if the `status` field contains a 4xx error. If so, send it to Elasticsearch. Finally, send all apache status codes to statsd no matter what the `status` field contains: -[source,js] ----------------------------------- +```js output { if [type] == "apache" { if [status] =~ /^5\d\d/ { @@ -199,16 +190,16 @@ output { statsd { increment => "apache.%{status}" } } } ----------------------------------- +``` -[discrete] -==== Processing Syslog messages -Syslog is one of the most common use cases for Logstash, and one it handles exceedingly well (as long as the log lines conform roughly to RFC3164). Syslog is the de facto UNIX networked logging standard, sending messages from client machines to a local file, or to a centralized log server via rsyslog. For this example, you won't need a functioning syslog instance; we'll fake it from the command line so you can get a feel for what happens. -First, let's make a simple configuration file for Logstash + syslog, called 'logstash-syslog.conf'. +## Processing Syslog messages [_processing_syslog_messages] -[source,ruby] ----------------------------------- +Syslog is one of the most common use cases for Logstash, and one it handles exceedingly well (as long as the log lines conform roughly to RFC3164). Syslog is the de facto UNIX networked logging standard, sending messages from client machines to a local file, or to a centralized log server via rsyslog. For this example, you won’t need a functioning syslog instance; we’ll fake it from the command line so you can get a feel for what happens. + +First, let’s make a simple configuration file for Logstash + syslog, called *logstash-syslog.conf*. + +```ruby input { tcp { port => 5000 @@ -237,36 +228,32 @@ output { elasticsearch { hosts => ["localhost:9200"] } stdout { codec => rubydebug } } ----------------------------------- +``` Run Logstash with this new configuration: -[source,ruby] ----------------------------------- +```ruby bin/logstash -f logstash-syslog.conf ----------------------------------- +``` -Normally, a client machine would connect to the Logstash instance on port 5000 and send its message. For this example, we'll just telnet to Logstash and enter a log line (similar to how we entered log lines into STDIN earlier). Open another shell window to interact with the Logstash syslog input and enter the following command: +Normally, a client machine would connect to the Logstash instance on port 5000 and send its message. For this example, we’ll just telnet to Logstash and enter a log line (similar to how we entered log lines into STDIN earlier). Open another shell window to interact with the Logstash syslog input and enter the following command: -[source,ruby] ----------------------------------- +```ruby telnet localhost 5000 ----------------------------------- +``` Copy and paste the following lines as samples. (Feel free to try some of your own, but keep in mind they might not parse if the `grok` filter is not correct for your data). -[source,ruby] ----------------------------------- +```ruby Dec 23 12:11:43 louis postfix/smtpd[31499]: connect from unknown[95.75.93.154] Dec 23 14:42:56 louis named[16000]: client 199.48.164.7#64817: query (cache) 'amsterdamboothuren.com/MX/IN' denied Dec 23 14:30:01 louis CRON[619]: (www-data) CMD (php /usr/share/cacti/site/poller.php >/dev/null 2>/var/log/cacti/poller-error.log) Dec 22 18:28:06 louis rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="2253" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'. ----------------------------------- +``` Now you should see the output of Logstash in your original shell as it processes and parses messages! -[source,ruby] ----------------------------------- +```ruby { "message" => "Dec 23 14:30:01 louis CRON[619]: (www-data) CMD (php /usr/share/cacti/site/poller.php >/dev/null 2>/var/log/cacti/poller-error.log)", "@timestamp" => "2013-12-23T22:30:01.000Z", @@ -285,7 +272,5 @@ Now you should see the output of Logstash in your original shell as it processes "syslog_facility" => "user-level", "syslog_severity" => "notice" } ----------------------------------- - - +``` diff --git a/docs/reference/config-setting-files.md b/docs/reference/config-setting-files.md new file mode 100644 index 000000000..5ace59d73 --- /dev/null +++ b/docs/reference/config-setting-files.md @@ -0,0 +1,33 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/config-setting-files.html +--- + +# Logstash Configuration Files [config-setting-files] + +Logstash has two types of configuration files: *pipeline configuration files*, which define the Logstash processing pipeline, and *settings files*, which specify options that control Logstash startup and execution. + +## Pipeline Configuration Files [pipeline-config-files] + +You create pipeline configuration files when you define the stages of your Logstash processing pipeline. On deb and rpm, you place the pipeline configuration files in the `/etc/logstash/conf.d` directory. Logstash tries to load only files with `.conf` extension in the `/etc/logstash/conf.d directory` and ignores all other files. + +See [*Creating a {{ls}} pipeline*](/reference/creating-logstash-pipeline.md) for more info. + + +## Settings Files [settings-files] + +The settings files are already defined in the Logstash installation. Logstash includes the following settings files: + +**`logstash.yml`** +: Contains Logstash configuration flags. You can set flags in this file instead of passing the flags at the command line. Any flags that you set at the command line override the corresponding settings in the `logstash.yml` file. See [logstash.yml](/reference/logstash-settings-file.md) for more info. + +**`pipelines.yml`** +: Contains the framework and instructions for running multiple pipelines in a single Logstash instance. See [Multiple Pipelines](/reference/multiple-pipelines.md) for more info. + +**`jvm.options`** +: Contains JVM configuration flags. Use this file to set initial and maximum values for total heap space. You can also use this file to set the locale for Logstash. Specify each flag on a separate line. All other settings in this file are considered expert settings. + +**`log4j2.properties`** +: Contains default settings for `log4j 2` library. See [Log4j2 configuration](/reference/logging.md#log4j2) for more info. + + diff --git a/docs/reference/configuration-file-structure.md b/docs/reference/configuration-file-structure.md new file mode 100644 index 000000000..f98459640 --- /dev/null +++ b/docs/reference/configuration-file-structure.md @@ -0,0 +1,235 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html +--- + +# Structure of a pipeline [configuration-file-structure] + +A {{ls}} pipeline config file has a separate section for each type of plugin you want to add to the event processing pipeline. For example: + +```js +# This is a comment. You should use comments to describe +# parts of your configuration. +input { + ... +} + +filter { + ... +} + +output { + ... +} +``` + +Each section contains configuration options for one or more plugins. If you specify multiple filters, they are applied in the order they appear in the configuration file. If you specify multiple outputs, events are sent to each destination sequentially, in the order they appear in the configuration file. + +::::{tip} +When you are ready to deploy a pipeline beyond your local machine, add the pipeline config file to [`logstash.yml`](/reference/logstash-settings-file.md) using the `pipeline.id` setting. When you are ready to deploy [multiple pipelines](/reference/multiple-pipelines.md), set up and configure your pipelines in the `pipelines.yml` file. +:::: + + + +## Plugin configuration [plugin_configuration] + +A plugin configuration consists of the plugin name followed by a block of settings for that plugin. For example, this input section configures two file inputs: + +```js +input { + http { + port => 3333 + tags => gateway + } + http { + port => 4444 + tags => billing + } +} +``` + +In this example, two settings are configured for each of the file inputs: *port* and *tags*. + +The settings you can configure vary according to the plugin type. For information about each plugin, see [Input Plugins](/reference/input-plugins.md), [Output Plugins](/reference/output-plugins.md), [Filter Plugins](/reference/filter-plugins.md), and [Codec Plugins](/reference/codec-plugins.md). + + +## Value types [plugin-value-types] + +A plugin can require that the value for a setting be a certain type, such as boolean, list, or hash. The following value types are supported. + +## Array [array] + +This type is now mostly deprecated in favor of using a standard type like `string` with the plugin defining the `:list => true` property for better type checking. It is still needed to handle lists of hashes or mixed types where type checking is not desired. + +Example: + +```js + users => [ {id => 1, name => bob}, {id => 2, name => jane} ] +``` + + +### Lists [list] + +Not a type in and of itself, but a property types can have. This makes it possible to type check multiple values. Plugin authors can enable list checking by specifying `:list => true` when declaring an argument. + +Example: + +```js + path => [ "/var/log/messages", "/var/log/*.log" ] + uris => [ "http://elastic.co", "http://example.net" ] +``` + +This example configures `path`, which is a `string` to be a list that contains an element for each of the three strings. It also will configure the `uris` parameter to be a list of URIs, failing if any of the URIs provided are not valid. + + +### Boolean [boolean] + +A boolean must be either `true` or `false`. Note that the `true` and `false` keywords are not enclosed in quotes. + +Example: + +```js + ssl_enable => true +``` + + +### Bytes [bytes] + +A bytes field is a string field that represents a valid unit of bytes. It is a convenient way to declare specific sizes in your plugin options. Both SI (k M G T P E Z Y) and Binary (Ki Mi Gi Ti Pi Ei Zi Yi) units are supported. Binary units are in base-1024 and SI units are in base-1000. This field is case-insensitive and accepts space between the value and the unit. If no unit is specified, the integer string represents the number of bytes. + +Examples: + +```js + my_bytes => "1113" # 1113 bytes + my_bytes => "10MiB" # 10485760 bytes + my_bytes => "100kib" # 102400 bytes + my_bytes => "180 mb" # 180000000 bytes +``` + + +### Codec [codec] + +A codec is the name of Logstash codec used to represent the data. Codecs can be used in both inputs and outputs. + +Input codecs provide a convenient way to decode your data before it enters the input. Output codecs provide a convenient way to encode your data before it leaves the output. Using an input or output codec eliminates the need for a separate filter in your Logstash pipeline. + +A list of available codecs can be found at the [Codec Plugins](/reference/codec-plugins.md) page. + +Example: + +```js + codec => "json" +``` + + +### Hash [hash] + +A hash is a collection of key value pairs specified in the format `"field1" => "value1"`. Note that multiple key value entries are separated by spaces rather than commas. + +Example: + +```js +match => { + "field1" => "value1" + "field2" => "value2" + ... +} +# or as a single line. No commas between entries: +match => { "field1" => "value1" "field2" => "value2" } +``` + + +### Number [number] + +Numbers must be valid numeric values (floating point or integer). + +Example: + +```js + port => 33 +``` + + +### Password [password] + +A password is a string with a single value that is not logged or printed. + +Example: + +```js + my_password => "password" +``` + + +### URI [uri] + +A URI can be anything from a full URL like *http://elastic.co/* to a simple identifier like *foobar*. If the URI contains a password such as *http://user:pass@example.net* the password portion of the URI will not be logged or printed. + +Example: + +```js + my_uri => "http://foo:bar@example.net" +``` + + +### Path [path] + +A path is a string that represents a valid operating system path. + +Example: + +```js + my_path => "/tmp/logstash" +``` + + +### String [string] + +A string must be a single character sequence. Note that string values are enclosed in quotes, either double or single. + +### Escape sequences [_escape_sequences] + +By default, escape sequences are not enabled. If you wish to use escape sequences in quoted strings, you will need to set `config.support_escapes: true` in your `logstash.yml`. When `true`, quoted strings (double and single) will have this transformation: + +| | | +| --- | --- | +| Text | Result | +| \r | carriage return (ASCII 13) | +| \n | new line (ASCII 10) | +| \t | tab (ASCII 9) | +| \\ | backslash (ASCII 92) | +| \" | double quote (ASCII 34) | +| \' | single quote (ASCII 39) | + +Example: + +```js + name => "Hello world" + name => 'It\'s a beautiful day' +``` + + +### Field reference [field-reference] + +A Field Reference is a special [String](#string) value representing the path to a field in an event, such as `@timestamp` or `[@timestamp]` to reference a top-level field, or `[client][ip]` to access a nested field. The [*Field References Deep Dive*](https://www.elastic.co/guide/en/logstash/current/field-references-deepdive.html) provides detailed information about the structure of Field References. When provided as a configuration option, Field References need to be quoted and special characters must be escaped following the same rules as [String](#string). + + +## Comments [comments] + +Comments are the same as in perl, ruby, and python. A comment starts with a *#* character, and does not need to be at the beginning of a line. For example: + +```js +# this is a comment + +input { # comments can appear at the end of a line, too + # ... +} +``` + +::::{note} +Comments containing environment variable `${var}` references in `config.string` are still evaluated. Remove the `$` sign to avoid pipeline loading failures. +:::: + + + + diff --git a/docs/reference/configuring-centralized-pipelines.md b/docs/reference/configuring-centralized-pipelines.md new file mode 100644 index 000000000..fc56a4a4f --- /dev/null +++ b/docs/reference/configuring-centralized-pipelines.md @@ -0,0 +1,157 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/configuring-centralized-pipelines.html +--- + +# Configure Centralized Pipeline Management [configuring-centralized-pipelines] + +To configure [centralized pipeline management](/reference/logstash-centralized-pipeline-management.md): + +1. Verify that you are using a license that includes the pipeline management feature. + + For more information, see [https://www.elastic.co/subscriptions](https://www.elastic.co/subscriptions) and [License management](docs-content://deploy-manage/license/manage-your-license-in-self-managed-cluster.md). + +2. Specify [configuration management settings](#configuration-management-settings) in the `logstash.yml` file. At a minimum, set: + + * `xpack.management.enabled: true` to enable centralized configuration management. + * `xpack.management.elasticsearch.hosts` to specify the Elasticsearch instance that will store the Logstash pipeline configurations and metadata. + * `xpack.management.pipeline.id` to register the pipelines that you want to centrally manage. + +3. Restart Logstash. +4. If your Elasticsearch cluster is protected with basic authentication, assign the built-in `logstash_admin` role as well as the `logstash_writer` role to any users who will use centralized pipeline management. See [Secure your connection](/reference/secure-connection.md) for more information. + +::::{note} +Centralized management is disabled until you configure and enable {{security-features}}. +:::: + + +::::{important} +After you’ve configured Logstash to use centralized pipeline management, you can no longer specify local pipeline configurations. This means that the `pipelines.yml` file and settings like `path.config` and `config.string` are inactive when this feature is enabled. +:::: + + +## Configuration Management Settings in Logstash [configuration-management-settings] + + +You can set the following `xpack.management` settings in `logstash.yml` to enable [centralized pipeline management](/reference/logstash-centralized-pipeline-management.md). For more information about configuring Logstash, see [logstash.yml](/reference/logstash-settings-file.md). + +The following example shows basic settings that assume {{es}} and {{kib}} are installed on the localhost with basic AUTH enabled, but no SSL. If you’re using SSL, you need to specify additional SSL settings. + +```shell +xpack.management.enabled: true +xpack.management.elasticsearch.hosts: "http://localhost:9200/" +xpack.management.elasticsearch.username: logstash_admin_user +xpack.management.elasticsearch.password: t0p.s3cr3t +xpack.management.logstash.poll_interval: 5s +xpack.management.pipeline.id: ["apache", "cloudwatch_logs"] +``` + +`xpack.management.enabled` +: Set to `true` to enable {{xpack}} centralized configuration management for Logstash. + +`xpack.management.logstash.poll_interval` +: How often the Logstash instance polls for pipeline changes from Elasticsearch. The default is 5s. + +`xpack.management.pipeline.id` +: Specify a comma-separated list of pipeline IDs to register for centralized pipeline management. After changing this setting, you need to restart Logstash to pick up changes. Pipeline IDs support `*` as a [wildcard](#wildcard-in-pipeline-id) for matching multiple IDs + +`xpack.management.elasticsearch.hosts` +: The {{es}} instance that will store the Logstash pipeline configurations and metadata. This might be the same {{es}} instance specified in the `outputs` section in your Logstash configuration, or a different one. Defaults to `http://localhost:9200`. + +`xpack.management.elasticsearch.username` and `xpack.management.elasticsearch.password` +: If your {{es}} cluster is protected with basic authentication, these settings provide the username and password that the Logstash instance uses to authenticate for accessing the configuration data. The username you specify here should have the built-in `logstash_admin` and `logstash_system` roles. These roles provide access to system indices for managing configurations. + +::::{note} +Starting with Elasticsearch version 7.10.0, the `logstash_admin` role inherits the `manage_logstash_pipelines` cluster privilege for centralized pipeline management. If a user has created their own roles and granted them access to the .logstash index, those roles will continue to work in 7.x but will need to be updated for 8.0. +:::: + + +`xpack.management.elasticsearch.proxy` +: Optional setting that allows you to specify a proxy URL if Logstash needs to use a proxy to reach your Elasticsearch cluster. + +`xpack.management.elasticsearch.ssl.ca_trusted_fingerprint` +: Optional setting that enables you to specify the hex-encoded SHA-256 fingerprint of the certificate authority for your {{es}} instance. + +::::{note} +A self-secured Elasticsearch cluster will provide the fingerprint of its CA to the console during setup. + +You can also get the SHA256 fingerprint of an Elasticsearch’s CA using the `openssl` command-line utility on the Elasticsearch host: + +```shell +openssl x509 -fingerprint -sha256 -in $ES_HOME/config/certs/http_ca.crt +``` + +:::: + + +`xpack.management.elasticsearch.ssl.certificate_authority` +: Optional setting that enables you to specify a path to the `.pem` file for the certificate authority for your {{es}} instance. + +`xpack.management.elasticsearch.ssl.truststore.path` +: Optional setting that provides the path to the Java keystore (JKS) to validate the server’s certificate. + +::::{note} +You cannot use this setting and `xpack.management.elasticsearch.ssl.certificate_authority` at the same time. +:::: + + +`xpack.management.elasticsearch.ssl.truststore.password` +: Optional setting that provides the password to the truststore. + +`xpack.management.elasticsearch.ssl.keystore.path` +: Optional setting that provides the path to the Java keystore (JKS) to validate the client’s certificate. + +::::{note} +You cannot use this setting and `xpack.management.elasticsearch.ssl.keystore.certificate` at the same time. +:::: + + +`xpack.management.elasticsearch.ssl.keystore.password` +: Optional setting that provides the password to the keystore. + +`xpack.management.elasticsearch.ssl.certificate` +: Optional setting that provides the path to an SSL certificate to use to authenticate the client. This certificate should be an OpenSSL-style X.509 certificate file. + +::::{note} +This setting can be used only if `xpack.management.elasticsearch.ssl.key` is set. +:::: + + +`xpack.management.elasticsearch.ssl.key` +: Optional setting that provides the path to an OpenSSL-style RSA private key that corresponds to the `xpack.management.elasticsearch.ssl.certificate`. + +::::{note} +This setting can be used only if `xpack.management.elasticsearch.ssl.certificate` is set. +:::: + + +`xpack.management.elasticsearch.ssl.verification_mode` +: Option to validate the server’s certificate. Defaults to `full`. To disable, set to `none`. Disabling this severely compromises security. + +`xpack.management.elasticsearch.ssl.cipher_suites` +: Optional setting that provides the list of cipher suites to use, listed by priorities. Supported cipher suites vary depending on the Java and protocol versions. + +`xpack.management.elasticsearch.cloud_id` +: If you’re using {{es}} in {{ecloud}}, you should specify the identifier here. This setting is an alternative to `xpack.management.elasticsearch.hosts`. If `cloud_id` is configured, `xpack.management.elasticsearch.hosts` should not be used. This {{es}} instance will store the Logstash pipeline configurations and metadata. + +`xpack.management.elasticsearch.cloud_auth` +: If you’re using {{es}} in {{ecloud}}, you can set your auth credentials here. This setting is an alternative to both `xpack.management.elasticsearch.username` and `xpack.management.elasticsearch.password`. If `cloud_auth` is configured, those settings should not be used. The credentials you specify here should be for a user with the `logstash_admin` and `logstash_system` roles, which provide access to system indices for managing configurations. + +`xpack.management.elasticsearch.api_key` +: Authenticate using an Elasticsearch API key. Note that this option also requires using SSL. The API key Format is `id:api_key` where `id` and `api_key` are as returned by the Elasticsearch [Create API key API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-security-create-api-key). + + +## Wildcard support in pipeline ID [wildcard-in-pipeline-id] + + +Pipeline IDs must begin with a letter or underscore and contain only letters, underscores, dashes, and numbers. You can use `*` in `xpack.management.pipeline.id` to match any number of letters, underscores, dashes, and numbers. + +```shell +xpack.management.pipeline.id: ["*logs", "*apache*", "tomcat_log"] +``` + +In this example, `"*logs"` matches all IDs ending in `logs`. `"*apache*"` matches any IDs with `apache` in the name. + +Wildcard in pipeline IDs is available starting with Elasticsearch 7.10. Logstash can pick up new pipeline without a restart if the new pipeline ID matches the wildcard pattern. + + diff --git a/docs/reference/configuring-geoip-database-management.md b/docs/reference/configuring-geoip-database-management.md new file mode 100644 index 000000000..df0f84a2a --- /dev/null +++ b/docs/reference/configuring-geoip-database-management.md @@ -0,0 +1,68 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/configuring-geoip-database-management.html +--- + +# Configure GeoIP Database Management [configuring-geoip-database-management] + +To configure [GeoIP Database Management](/reference/logstash-geoip-database-management.md): + +1. Verify that you are using a license that includes the geoip database management feature. + + For more information, see [https://www.elastic.co/subscriptions](https://www.elastic.co/subscriptions) and [License management](docs-content://deploy-manage/license/manage-your-license-in-self-managed-cluster.md). + +2. Specify [geoip database management settings](#geoip-database-management-settings) in the `logstash.yml` file to tune the configuration as-needed. + +## GeoIP database Management settings in {{ls}} [geoip-database-management-settings] + + +You can set the following `xpack.geoip` settings in `logstash.yml` to configure the [geoip database manager](/reference/logstash-geoip-database-management.md). For more information about configuring Logstash, see [logstash.yml](/reference/logstash-settings-file.md). + +`xpack.geoip.downloader.enabled` +: (Boolean) If `true`, Logstash automatically downloads and manages updates for GeoIP2 databases from the `xpack.geoip.downloader.endpoint`. If `false`, Logstash does not manage GeoIP2 databases and plugins that need a GeoIP2 database must be configured to provide their own. + +`xpack.geoip.downloader.endpoint` +: (String) Endpoint URL used to download updates for GeoIP2 databases. For example, `https://mydomain.com/overview.json`. Defaults to `https://geoip.elastic.co/v1/database`. Note that Logstash will periodically make a GET request to `${xpack.geoip.downloader.endpoint}?elastic_geoip_service_tos=agree`, expecting the list of metadata about databases typically found in `overview.json`. + +`xpack.geoip.downloader.poll.interval` +: (Time Value) How often Logstash checks for GeoIP2 database updates at the `xpack.geoip.downloader.endpoint`. For example, `6h` to check every six hours. Defaults to `24h` (24 hours). + + +## Offline and air-gapped environments [configuring-geoip-database-management-offline] + +If Logstash does not have access to the internet, or if you want to disable the database manager, set the `xpack.geoip.downloader.enabled` value to `false` in `logstash.yml`. When the database manager is disabled, plugins that require GeoIP lookups must be configured with their own source of GeoIP databases. + +### Using an HTTP proxy [_using_an_http_proxy] + +If you can’t connect directly to the Elastic GeoIP endpoint, consider setting up an HTTP proxy server. You can then specify the proxy with `http_proxy` environment variable. + +```sh +export http_proxy="http://PROXY_IP:PROXY_PORT" +``` + + +### Using a custom endpoint [_using_a_custom_endpoint] + +If you work in an air-gapped environment and can’t update your databases from the Elastic endpoint, You can then download databases from MaxMind and bootstrap the service. + +1. Download both `GeoLite2-ASN.mmdb` and `GeoLite2-City.mmdb` database files from the [MaxMind site](http://dev.maxmind.com/geoip/geoip2/geolite2). +2. Copy both database files to a single directory. +3. [Download {{es}}](https://www.elastic.co/downloads/elasticsearch). +4. From your {{es}} directory, run: + + ```sh + ./bin/elasticsearch-geoip -s my/database/dir + ``` + +5. Serve the static database files from your directory. For example, you can use Docker to serve the files from nginx server: + + ```sh + docker run -p 8080:80 -v my/database/dir:/usr/share/nginx/html:ro nginx + ``` + +6. Specify the service’s endpoint URL in Logstash using the `xpack.geoip.download.endpoint=http://localhost:8080/overview.json` setting in `logstash.yml`. + +Logstash gets automatic updates from this service. + + + diff --git a/docs/reference/connecting-to-cloud.md b/docs/reference/connecting-to-cloud.md new file mode 100644 index 000000000..7bb7fcc24 --- /dev/null +++ b/docs/reference/connecting-to-cloud.md @@ -0,0 +1,47 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/logstash/current/connecting-to-cloud.html +--- + +# Sending data to Elastic Cloud (hosted Elasticsearch Service) [connecting-to-cloud] + +Our hosted {{ess}} on [Elastic Cloud](https://cloud.elastic.co/) simplifies safe, secure communication between {{ls}} and {{es}}. When you configure the Elasticsearch output plugin to use [`cloud_id`](/reference/plugins-outputs-elasticsearch.md#plugins-outputs-elasticsearch-cloud_id) with either the [`cloud_auth` option](/reference/plugins-outputs-elasticsearch.md#plugins-outputs-elasticsearch-cloud_auth) or the [`api_key` option](/reference/plugins-outputs-elasticsearch.md#plugins-outputs-elasticsearch-api_key), no additional SSL configuration is needed. + +Examples: + +* `output {elasticsearch { cloud_id => "" cloud_auth => "" } }` +* `output {elasticsearch { cloud_id => "" api_key => "" } }` + +{ess-leadin-short} + +## Cloud ID [cloud-id] + +{{ls}} uses the Cloud ID, found in the Elastic Cloud web console, to build the Elasticsearch and Kibana hosts settings. It is a base64 encoded text value of about 120 characters made up of upper and lower case letters and numbers. If you have several Cloud IDs, you can add a label, which is ignored internally, to help you tell them apart. To add a label you should prefix your Cloud ID with a label and a `:` separator in this format "