-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Logs+] Implement Data Source APIs #156413
[Logs+] Implement Data Source APIs #156413
Conversation
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
a08f399
to
c497919
Compare
46110f0
to
ed121b5
Compare
@@ -21,14 +21,17 @@ export const LIMITED_CONCURRENCY_ROUTE_TAG = 'ingest:limited-concurrency'; | |||
|
|||
// EPM API routes | |||
const EPM_PACKAGES_MANY = `${EPM_API_ROOT}/packages`; | |||
const EPM_PACKAGES_INSTALLED = `${EPM_API_ROOT}/packages/installed`; |
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.
Based on advice here: https://github.com/elastic/observability-dev/issues/2639#issuecomment-1521689096
@@ -24,3 +24,5 @@ export interface DataStream { | |||
serviceName: string; | |||
} | null; | |||
} | |||
|
|||
export type PackageDataStreamTypes = 'logs' | 'metrics' | 'traces' | 'synthetics' | 'profiling'; |
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.
Possibly not the best naming, or location? But when looking at other Fleet code I could only really find the DATA_STREAM_INDEX_PATTERN
constant, but not a type I could reuse.
@@ -46,6 +49,26 @@ export interface GetPackagesResponse { | |||
response?: PackageList; | |||
} | |||
|
|||
interface InstalledPackage { |
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 fairly minimal, and doesn't necessarily align with the advice given, r.e.:
I do think we should make sure the response body is somewhat aligned with the rest of the Fleet API's patterns though for consistency
Extra properties would have required extra queries to other locations (e.g. the registry), which is why this is so minimal.
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 think it makes sense to keep the API response minimal to avoid extra queries, we can add more fields later if needed for other use cases.
dataset: datasetQuery ? `*${datasetQuery}*` : '*', | ||
}); | ||
|
||
const filteredDataStreams = uncategorisedOnly |
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.
Not sure if this is the best name? But we need some sort of option that can differentiate between wanting all data streams or only wanting uncategorised ones, this will be important for the work within Discover.
? [ | ||
buildFunctionNode( | ||
'nested', | ||
`${PACKAGES_SAVED_OBJECT_TYPE}.attributes.installed_es`, |
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 use installed_es
here as other properties within the SO aren't mapped, and therefore aren't queryable. We need something top level so that we can take advantage of pagination on the Saved Objects.
Pinging @elastic/fleet (Team:Fleet) |
@juliaElastic I think this is ready for another look (once green).
Otherwise everything has been actioned. |
@Kerry350 Looks great! Added a few comments. I think we should test at least manually that the permissions work as expected. Is this the expected behavior?
I would appreciate if you opened an issue in kibana, we can investigate. |
Yep, I've given this a test locally manually with a specific role and user, but a second pair of eyes is appreciated.
Correct 👍 For the data streams one they will also need the
Correct 👍
I've been using elastic-package for my testing, running with
R.e. tests and this issue I think I've found the issue, although I still seem to be getting the occasional leaky state issue when running my tests. When I did a log of the packages I was getting returned in my tests the two rogue (in the sense they had nothing to do with that file of tests) packages I could see were:
Looking at
I managed to find the I'll let CI run and see what sort of results I get - I expect there to be 3 packages involved in these new tests now (and before the addition of the cleanup I'd get 5). |
Interesting 🤔 I've just double checked with the same and things are working. Request: Auth: Index privileges: Kibana privileges: Was your request possibly missing the As a side note: maybe this should be flipped to the default being |
Yes, this was it, with the parameter I get the expected results.
Yes, it sounds more intuitive to me to return all results without any parameters. |
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, tested locally.
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
Page load bundle
Unknown metric groupsAPI count
ESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: cc @Kerry350 |
## Summary Research: https://github.com/elastic/observability-dev/issues/2620 Requirements: https://github.com/elastic/observability-dev/issues/2639 Implementation: https://github.com/elastic/observability-dev/issues/2653 This implements two APIs ("Enumerate integrations" and "Enumerate data streams") under the Fleet plugin, and specifically the `/epm` namespace given the input here: https://github.com/elastic/observability-dev/issues/2639#issuecomment-1521689096 The Enumerate Integrations API can be queried like so (example with all parameters): `GET /api/fleet/epm/packages/installed?nameQuery=system&pageSize=5&type=logs&pageAfter=["system"]&sortDirection=asc` The Enumerate Data Streams API can be queried like so (example with all parameters): `GET /api/fleet/epm/data_streams?uncategorisedOnly=true&type=logs&sortDirection=desc&datasetQuery=beat`
Summary
Research: https://github.com/elastic/logs-dev/issues/97
Requirements: https://github.com/elastic/logs-dev/issues/94
Implementation: https://github.com/elastic/logs-dev/issues/95
This implements two APIs ("Enumerate integrations" and "Enumerate data streams") under the Fleet plugin, and specifically the
/epm
namespace given the input here: https://github.com/elastic/logs-dev/issues/94The Enumerate Integrations API can be queried like so (example with all parameters):
GET /api/fleet/epm/packages/installed?nameQuery=system&pageSize=5&type=logs&pageAfter=["system"]&sortDirection=asc
The Enumerate Data Streams API can be queried like so (example with all parameters):
GET /api/fleet/epm/data_streams?uncategorisedOnly=true&type=logs&sortDirection=desc&datasetQuery=beat
I've also left some inline review comments.
Notes / questions
There is an
uncategorisedOnly
option as part of the Data Streams API to exclude streams which are owned and managed by Fleet (so this would be streams that adhere to the spec 100%, but don't have the managed by property). This will be necessary for Discover (and perhaps other uses) to make a differentiation.We are trying to make this API performant, and we therefore want to paginate for the first API (we can't on the second one as the Data Streams APIs aren't flexible enough).I think this has the caveat that we can't filter bytype
at the top level of the package Saved Objects query, as we would need to query for objects where "one of the values ofes_index_patterns
contains XYZ...". The inner data streams are filtered, but we'll likely end up withtype
-less integrations to display in our log source selector. We can't just filter them server side as this will obviously alter the pagination. Will disabling / greying out these entries be acceptable UX? Is there some combination of querying on the SOs that I've missed?installed_es.type
andinstalled_es.id
properties to achieve this and maintain top level pagination integrity.Similar to above, as we're trying to make this as performant as possible it's hard to query certain properties without taking a performance hit. In particular there isn't an easy way to query for icons. Icons are usually queried viaRegistry.fetchList()
, this fetches all integrations from the registry. To use this we would have to forego our pagination benefits on the SO side, as the API doesn't support pagination. There is afetchInfo
method, but this queries for one. There isn't a way to pass an array of IDs (as an example) to these APIs, so we'd have to make one call per package. I imagine we'll use a page size of around 30, so this would be another 30 requests. The current data streams API (the one not under the/epm
namespace) suffers from this same problem, of having to query from many locations and combine the information. If we use thePackageIcon
component from Fleet withtryAPI=true
we could at least defer the loading, giving priority to getting the names and datasets on the page, however this still ultimately ends up with multiple requests toapi/fleet/epm/packages/<package_name>/<version>
- but shifted from server to client. This component does make optimisations such as usingloading=lazy
on theimg
but it's likely our selector will be displaying everything in the viewport anyway once it's open. The icons seem fairly important within our UX, how should we tackle this? Adding capabilities to this API: https://github.com/elastic/package-registry/blob/f1b859c61c243b445873ac938236c64ffbb3a7f6/search.go#L27 seems fairly difficult.usePackageIconType
requires (packageName
andversion
).The permissions model within Fleet is very custom. There is the use of
FleetAuthz
and this allows the use of a custom Saved Objects client that is "configured to use kibana_system privileges instead of end-user privileges". I don't think we want to have these strict authorisation requirements for consuming these APIs within things like Discover. Rather, we'd want to only require permissions such asview_index_metadata
. I've used theasCurrentUser
version of the ES client (will requireview_index_metadata
), and the "standard"savedObjects.client
(as in, from the router core context, not Fleet's custom version). This will still require the Kibana > Management > Integrations > Read permission as a minimum to query for the package Saved Objects. Are we okay with these two permission requirements? Even living outside of the Fleet plugin this would be the case. Has this introduced any security issues?kibana_system
user so that the end user doesn't need specific permissions. We'll need to clarify.