-
Notifications
You must be signed in to change notification settings - Fork 531
ECE Adminconsole logs #13864
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
ECE Adminconsole logs #13864
Conversation
|
In observability we don't have a way yet to add alert presets to integrations (it's something we want to have at some point). I believe security have a way to add OOTB alerts CC @jamiehynds for details |
Thanks for the contribution @philippkahr. Although not particularly common, security rules are a supported asset type with integrations (see here). As for a responsible team for PR review and ownership of this integration - the stack management team may be the best fit @consulthys is the PM on that team. |
Did you mean Stack Monitoring? |
Sorry, yes. Stack Monitoring. |
|
@philippkahr can you elaborate on the nature of those logs? Are they the same or similar in nature as what is being collected here for Cloud customers? |
@consulthys hmm good question actually. I would say that this data is from the same origin. This takes the |
|
Can we get some traction on this? |
|
@philippkahr Integrations are open and anyone can contribute, so I'd say feel free to get a crack at it and release it as beta once you've ensured that everything works properly. let me know once you think this PR is ready and we'll review it. |
|
Hi! We just realized that we haven't looked into this PR in a while. We're sorry! We're labeling this issue as |
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.
Had a chat today with Philip on this one, just adding the review notes in case others might look at this.
Let's also figure out why it ended up being here so long and stalled.
EDIT: Would also be good to add system tests, since this is filestream based we could add that from any other filestream integration, it is a folder in the top _dev and the datastream _dev folder called system.
packages/ece_adminconsole/data_stream/log/_dev/test/pipeline/test-admincsole-log.log
Outdated
Show resolved
Hide resolved
packages/ece_adminconsole/data_stream/log/agent/stream/stream.yml.hbs
Outdated
Show resolved
Hide resolved
| title: Collect logs from ECE Adminconsole | ||
| description: Collecting the ECE Adminconsole logs | ||
| owner: | ||
| github: elastic/integrations |
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 have to decide on which team will own this, I will reach out and see if anyone can confirm what it should be.
packages/ece_adminconsole/data_stream/log/elasticsearch/ingest_pipeline/api.yml
Outdated
Show resolved
Hide resolved
|
Changes applied.
I deployed a local ECE, used terraform to create, delete instances, click around the UI. This generated a total of ~24.000 events that are all parsed succesfully. What am I waiting for to export the dashboard I made. |
|
Do I still need to do an |
|
@elastic/stack-monitoring @consulthys Can you review this PR? |
consulthys
left a comment
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.
Great job!! Just added a few comments
|
Hi! We just realized that we haven't looked into this PR in a while. We're sorry! We're labeling this issue as |
consulthys
left a comment
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.
LGT Stack Monitoring
|
@elastic/integrations-triaging can one of you check this PR and approve? You are still mentioned as pending review. |
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.
Looking into the failing tests build/test-results/ece-system-1768997174567033953.xml i see the fields used in the system test configuration are undefined.
You should add the fields to the base-fields.yml or a separate yml file to declare them so the test can assert them. @mrodm i am not sure what is the best case here, to add them to base-fields or create a separate file for them
- name: input.type
type: keyword
description: Input type
- name: log.offset
type: long
description: Log offset
- name: log.file.device_id
type: keyword
description: Device Id of the log file this event came from.
- name: log.file.inode
type: keyword
description: Inode number of the log file.
- name: log.file.fingerprint
type: keyword
description: Fingerprint of the log file.
You can check this out locally by running the system test, this is what i've done in case it helps:
- Run
elastic-package stack up -d -vto have a running stack - Position yourself under the package directory
/integrations/packages/eceand runelastic-package test system --data-streams adminconsole --report-output filethis will run the system tests and create a report under the folder/integrations/build/test-results. There you can find the details of the failing test. You can run alsoelastic-package test --report-output fileand this will run all of the test for the package.
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.
Looking into the failing tests build/test-results/ece-system-1768997174567033953.xml i see the fields used in the system test configuration are undefined.
Tests also are shown as a Buildkite annotation:

You should add the fields to the base-fields.yml or a separate yml file to declare them so the test can assert them. @mrodm i am not sure what is the best case here, to add them to base-fields or create a separate file for them
They can be located at any file. This is more related to how organize the fields in the package, since at the end all of the files are merged.
As this integration is using the filestream input, there are some examples in that input package that you could follow to add the missing field definitions:
integrations/packages/filestream/fields/beats.yml
Lines 1 to 3 in bab3bcf
| - name: input.type | |
| description: Type of Filebeat input. | |
| type: keyword |
integrations/packages/filestream/fields/filestream.yml
Lines 1 to 13 in bab3bcf
| - name: log.file.inode | |
| type: keyword | |
| description: | | |
| inode of the ingested file. | |
| - name: log.file.device_id | |
| type: keyword | |
| description: | | |
| device ID from the device where the file is. | |
| - name: log.file.fingerprint | |
| type: keyword | |
| index: false | |
| description: | | |
| The fingerprint of the file when using the fingerprint file identity. |
integrations/packages/filestream/fields/ecs.yml
Lines 5 to 6 in bab3bcf
| - name: log.offset | |
| description: Current log offset |
Should it be added other fields like log.file.path or log.level ?
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.
unmapped fields
~Why do I have to map unmapped fields such as log.file.path explicitly?
If your integration only supports Elastic Stack 8.13.0 and above: You can rely on the ecs@mappings component template installed by Fleet. This makes explicitly declaring ECS fields unnecessary; the ecs@mappings component template in Elasticsearch will automatically detect and configure them. However, should ECS fields be explicitly defined, they will overwrite the dynamic mapping provided by the ecs@mappings component template.
https://www.elastic.co/docs/extend/integrations/add-mapping#use-ecs~
I see that is on me, because we decided with filestream to introduce fields that are not part of ECS therefore I need to handle them explicitly. Very annoying, why does the elastic-package create ... not automatically create all of that boilerplate for me :(
I do wonder though why the elastic-package test doesn't cry about it?
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.
unmapped fields
~Why do I have to map unmapped fields such as
log.file.pathexplicitly?
I guess as they are port of ECS is not required to define those. So there is no need to add them 👍
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.
Looking into the failing tests build/test-results/ece-system-1768997174567033953.xml i see the fields used in the system test configuration are undefined.
Tests also are shown as a Buildkite annotation:

You should add the fields to the base-fields.yml or a separate yml file to declare them so the test can assert them. @mrodm i am not sure what is the best case here, to add them to base-fields or create a separate file for them
They can be located at any file. This is more related to how organize the fields in the package, since at the end all of the files are merged.
As this integration is using the filestream input, there are some examples in that input package that you could follow to add the missing field definitions:
integrations/packages/filestream/fields/beats.yml
Lines 1 to 3 in bab3bcf
| - name: input.type | |
| description: Type of Filebeat input. | |
| type: keyword |
integrations/packages/filestream/fields/filestream.yml
Lines 1 to 13 in bab3bcf
| - name: log.file.inode | |
| type: keyword | |
| description: | | |
| inode of the ingested file. | |
| - name: log.file.device_id | |
| type: keyword | |
| description: | | |
| device ID from the device where the file is. | |
| - name: log.file.fingerprint | |
| type: keyword | |
| index: false | |
| description: | | |
| The fingerprint of the file when using the fingerprint file identity. |
integrations/packages/filestream/fields/ecs.yml
Lines 5 to 6 in bab3bcf
| - name: log.offset | |
| description: Current log offset |
Should it be added other fields like log.file.path or log.level ?
🚀 Benchmarks reportTo see the full report comment with |
💚 Build Succeeded
History
|
mrodm
left a comment
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.
LGTM
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.
unmapped fields
~Why do I have to map unmapped fields such as
log.file.pathexplicitly?
I guess as they are port of ECS is not required to define those. So there is no need to add them 👍
|
Package ece - 0.0.1 containing this change is available at https://epr.elastic.co/package/ece/0.0.1/ |
Hey!
This is a big new integration that reads the adminconsole.ndjson. In certain enterprise setups we need an external tool that reads this file from the disk, for audit purposes. The log itself is already in NDJSON.
Currently this log is missing in the ECE logging-and-metrics cluster, but we need it in another cluster anyway.
I've created my own ECE, clicked through all the APIs and tried to capture all the needed documents. It is a bit rough here and there, but I wanted to prep it for future enhancements.
I haven't yet build any dashboards. What I would be after mostly is probably alerts but we cannot add alerts to integrations?
Checklist
changelog.ymlfile.Related issues
Integration UI
