Skip to content

Conversation

@philippkahr
Copy link
Contributor

@philippkahr philippkahr commented May 9, 2025

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

  • I have reviewed tips for building integrations and this pull request is aligned with them.
  • I have verified that all data streams collect metrics or logs.
  • I have added an entry to my package's changelog.yml file.
  • I have verified that Kibana version constraints are current according to guidelines.
  • I have verified that any added dashboard complies with Kibana's Dashboard good practices

Related issues

Integration UI
image

@philippkahr philippkahr requested a review from a team as a code owner May 9, 2025 13:02
@philippkahr philippkahr added the enhancement New feature or request label May 9, 2025
@andrewkroh andrewkroh added the New Integration Issue or pull request for creating a new integration package. label May 9, 2025
@daniela-elastic
Copy link

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

@jamiehynds
Copy link

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.

@consulthys
Copy link
Contributor

@jamiehynds

the stack management team may be the best fit @consulthys is the PM on that team.

Did you mean Stack Monitoring?

@jamiehynds
Copy link

@jamiehynds

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.

@consulthys
Copy link
Contributor

@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?

@philippkahr
Copy link
Contributor Author

@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 adminconsole.ndjson that is written to disk. This is available in ECE and it comes from the SDH, were we are not collecting this file. Additionally, we are not parsing it at all. That's why I generated this integration. I hope to properly parse it, configure it and ensure it is working.

@philippkahr
Copy link
Contributor Author

Can we get some traction on this?

@consulthys
Copy link
Contributor

consulthys commented Jul 1, 2025

@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.

@andrewkroh andrewkroh added the documentation Improvements or additions to documentation. Applied to PRs that modify *.md files. label Jul 1, 2025
@botelastic
Copy link

botelastic bot commented Jul 31, 2025

Hi! We just realized that we haven't looked into this PR in a while. We're sorry! We're labeling this issue as Stale to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1. Thank you for your contribution!

@botelastic botelastic bot added the Stalled label Jul 31, 2025
Copy link
Member

@P1llus P1llus left a 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.

title: Collect logs from ECE Adminconsole
description: Collecting the ECE Adminconsole logs
owner:
github: elastic/integrations
Copy link
Member

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.

@botelastic botelastic bot removed the Stalled label Aug 13, 2025
@philippkahr
Copy link
Contributor Author

philippkahr commented Aug 18, 2025

Changes applied.

  • No more ignore_failure processors replaced dissect with a simple GROK
  • Removed unnecessary pipeline calls
  • fixed mapping
  • renamed data stream.
  • copied a build system test over and modified so it should work

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.

@philippkahr
Copy link
Contributor Author

Do I still need to do an ecs.yml where I list all the fields I use from ECS?

@bhapas
Copy link
Contributor

bhapas commented Sep 8, 2025

@elastic/stack-monitoring @consulthys Can you review this PR?

@bhapas bhapas requested review from a team and consulthys September 17, 2025 07:29
Copy link
Contributor

@consulthys consulthys left a 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

@botelastic
Copy link

botelastic bot commented Jan 14, 2026

Hi! We just realized that we haven't looked into this PR in a while. We're sorry! We're labeling this issue as Stale to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1. Thank you for your contribution!

@botelastic botelastic bot added the Stalled label Jan 14, 2026
@botelastic botelastic bot removed the Stalled label Jan 19, 2026
Copy link
Contributor

@consulthys consulthys left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGT Stack Monitoring

@philippkahr
Copy link
Contributor Author

@elastic/integrations-triaging can one of you check this PR and approve? You are still mentioned as pending review.

Copy link
Contributor

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 -v to have a running stack
  • Position yourself under the package directory /integrations/packages/ece and run elastic-package test system --data-streams adminconsole --report-output file this 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 also elastic-package test --report-output file and this will run all of the test for the package.

Copy link
Collaborator

@mrodm mrodm Jan 23, 2026

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:
image

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:

- name: input.type
description: Type of Filebeat input.
type: keyword

- 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.

- name: log.offset
description: Current log offset

Should it be added other fields like log.file.path or log.level ?

Copy link
Contributor Author

@philippkahr philippkahr Jan 23, 2026

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?

Copy link
Collaborator

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?

I guess as they are port of ECS is not required to define those. So there is no need to add them 👍

Copy link
Collaborator

@mrodm mrodm Jan 23, 2026

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:
image

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:

- name: input.type
description: Type of Filebeat input.
type: keyword

- 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.

- name: log.offset
description: Current log offset

Should it be added other fields like log.file.path or log.level ?

@elastic-vault-github-plugin-prod

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

@elasticmachine
Copy link

💚 Build Succeeded

History

Copy link
Collaborator

@mrodm mrodm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Collaborator

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?

I guess as they are port of ECS is not required to define those. So there is no need to add them 👍

@philippkahr philippkahr merged commit 5da24e3 into elastic:main Jan 26, 2026
9 checks passed
@philippkahr philippkahr deleted the ece-adminconsole-logs branch January 26, 2026 12:17
@elastic-vault-github-plugin-prod

Package ece - 0.0.1 containing this change is available at https://epr.elastic.co/package/ece/0.0.1/

@andrewkroh andrewkroh added the Integration:ece Elastic Cloud Enterprise label Jan 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation. Applied to PRs that modify *.md files. enhancement New feature or request Integration:ece Elastic Cloud Enterprise New Integration Issue or pull request for creating a new integration package.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants