-
Notifications
You must be signed in to change notification settings - Fork 464
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[kibana] Simplify ECS formatted logs ingest pipelines #4175
[kibana] Simplify ECS formatted logs ingest pipelines #4175
Conversation
Should there be a new issue for this? The "closes" is currently pointing to a merged PR which points to a closed issue. |
I just realized I pointed to a wrong ticket now. |
@elasticmachine merge upstream |
/test |
🌐 Coverage report
|
server.ssl.certificateAuthorities: | ||
["/usr/share/kibana/config/certs/ca-cert.pem"] | ||
|
||
elasticsearch.hosts: ["https://elasticsearch:9200"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the stack-up elasticsearch right? I'm wondering if we should have this docker-compose launch both ES and kibana. Maybe even keep it simple and run them in http mode.
For example, do we know if the certs you have here are always going to work? I'd expect new launches of e-p stack up
to use new certs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the stack-up elasticsearch right?
yes!
For example, do we know if the certs you have here are always going to work? I'd expect new launches of e-p stack up to use new certs.
If they change the current certs, this will stop working. I had this in mind when I used the certs. But it probably can be simplified. We just need a Kibana instance that creates logs into /tmp/service_logs. This kibana service doesn't need fleet related stuff and could connect to a new ES instance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This kibana service doesn't need fleet related stuff and could connect to a new ES instance.
Yep, that's exactly what I'm thinking. Just keep the elastic-package service
docker compose as bare-bones as we need to generate good sample logs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ended up trying this and it seemed to work crespocarlos#2 but I only got server logs. Is there something we should add to produce some audit logs at this stage? or maybe we can leave that until the system test stage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm. Not really. Both logs should be created if enabled in kibana.yml. Let me fix the elastic-package service
setup for Kibana package and I'll check why audit logs are eventually not being created.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, audit logs are not generated unless you do some action with the kibana service instance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
xpack.security.enabled
has to be true
too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some review thoughts for you. I could see merging as-is and planning for more work once the test suite is more complete. Hard to validate all the corners manually.
if: "ctx?.user?.name != null" | ||
- pipeline: | ||
name: '{{ IngestPipeline "pipeline-json" }}' | ||
if: |- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be nice to align this conditional with https://github.com/elastic/integrations/blob/main/packages/elasticsearch/data_stream/server/elasticsearch/ingest_pipeline/default.yml#L15-L17
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This conditional was copied from platform-observability
package. It does seem like an overkill
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or if there's a reason for it, that's fine. But it'd be good to be consistent about how we say "this is a json message"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now looking at both approaches, here we need 4 processors in total to achieve what this does with 1. Besides, on elasticserach pipeline, apparently the document is dropped if message is not a json whereas here, the document is still ingested.
field: "*" | ||
override: true | ||
- join: | ||
field: error.stack_trace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This got me thinking that it'd be good to have stack trace sample logs from kibana to make sure this is the right behavior. Maybe not for this PR though.
@@ -8,7 +8,7 @@ If the Kibana instance is using a basepath in its URL, you must set the `basepat | |||
|
|||
## Compatibility | |||
|
|||
The `kibana` package works with Kibana 6.7.0 and later. | |||
The `kibana` package works with Kibana 8.5.0 and later. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. I've noticed this too. I'll try to find what's causing it
@@ -0,0 +1,78 @@ | |||
server.name: kibana |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I think I forgot to mention this (maybe lost in the github review cycle somewhere), but I opened crespocarlos#2 for an idea at simplifying the setup here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aha. Thanks. There's only one thing missing there. We need to reset the nevermind! It works :). I'll just try to get audit logs therekibana_system
user's password. It will still generate logs without that though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had to slightly complicate it in order to get audit logs there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kind of surprised audit logging would require use of a particular user, but I guess if it works it works :)
Review: [kibana] Simplify ECS formatted logs ingest pipelines
🚀 Benchmarks reportTo see the full report comment with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple visual inspection thoughts, I didn't try to run it today though.
image: "alpine/curl:latest" | ||
environment: | ||
- "ES_SERVICE_HOST=http://elasticsearch:9200" | ||
- "KIBANA_PASSWORD=changeme" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can do this to have it use the .env value
- "KIBANA_PASSWORD=changeme" | |
- KIBANA_PASSWORD |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good catch.
until curl --request POST $ES_SERVICE_HOST/_security/user/kibana_system/_password \ | ||
--user elastic:changeme \ | ||
--header 'Content-Type: application/json' \ | ||
--data "{\"password\":\"$KIBANA_PASSWORD\"}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went looking at how the ES docker docs did this to see if we should copy https://github.com/elastic/elasticsearch/blob/main/docs/reference/setup/install/docker/docker-compose.yml#L55-L56
But I think I like your rendition better :)
It looks like the audit logs are not produced. Maybe that is caused by my local docker version but I got the following logs:
|
We were not passing the ELASTIC_PASSWORD to the setup container, I've added it in c90afa9 |
@@ -0,0 +1,3 @@ | |||
ELASTIC_PASSWORD=changeme | |||
ELASTIC_VERSION=8.5.0-SNAPSHOT |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, we should export this variable in logstash/es package as well that'll make our life easier for #4013
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Logstash is done and elasticsearch is pending https://github.com/elastic/integrations/pull/4255/files
@@ -0,0 +1,2 @@ | |||
dynamic_fields: | |||
event.ingested: ".*" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have to ignore event.created
here ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No necessarily, because the event.created is copied from @timestamp, and it never changes, so the test won't fail if you don't ignore it.. event.ingested
is dynamic.
Thanks for spotting it, Kevin. I might have forgotten to push this change. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this PR do?
Closes #4047
This PR simplifies the logs ingest pipelines, since they are in ECS format, reusing what's has been done for the Platform Observability package
How to test this PR locally
cd packages/kibana && elastic-package build
elastic-package stack up -v -d --version 8.5.0-SNAPSHOT
cd packages/kibana && elastic-package service up -v