[microsoft_sqlserver] Add transaction log DataStream - #3395
Conversation
🌐 Coverage report
|
|
Pinging @elastic/integrations (Team:Integrations) |
|
Pinging @elastic/security-external-integrations (Team:Security-External Integrations) |
|
@ManojS-shetty @muthu-mps, @ruflin @jsoriano @r00tu53r, tar-getting the merge of this PR, need your approval for the same. |
|
The changes are done! |
jsoriano
left a comment
There was a problem hiding this comment.
It looks good in general, but I am concerned about some changes in versions.
| - name: driver | ||
| type: keyword | ||
| description: Driver used to execute the query. | ||
| - name: query |
There was a problem hiding this comment.
Actually, do we need the query at all in the final document? This is an implementation detail of the integration, I think that it could be removed.
But, if we are storing metrics coming from different queries in different documents we may need some dimension to distinguish between queries. So we may need to index the query to use it as dimension, or find some other field that could cover this.
We can also wait to have some way to join events (elastic/beats#31806 (comment)), then database_id will be probably enough as dimension.
|
/test |
jsoriano
left a comment
There was a problem hiding this comment.
Looks good, thanks for addressing all comments.
The main concern I would have now is about mssql.query. It is not clear to me if we are keeping it at the end or not.
Also I think that this data stream would benefit of elastic/beats#31806, to store all the metrics in the same document. And if we end up storing the results of the queries in the same document, what would we store in mssql.query? Would we remove it? This would be a breaking change.
The more I think about storing the query, the more I think that we shouldn't store it. And it is easier in any case to add it later if I am wrong, than to remove it if needed later.
jsoriano
left a comment
There was a problem hiding this comment.
LGTM, please remember to add pipeline tests at some moment
…mps/integrations into mssql_transaction_log_data_stream
* new changes for transaction datastream * codeowner and format changes * Naming changes for dashboard, updated img file * Name changes updated * kibana version upgraded to latest * Updated fields and added documentation * Added Readme file * Added Readme file * Added Readme file * Revert "Added Readme file" This reverts commit 13fbb8f6514e7ecfe533a426a3ed90c5da000095. ReadMe file changes * Revert "Updated fields and added documentation" This reverts commit ea08dd6e66f0b9b6139b68c78c6d187107c8c0c2. * Revert "Added Readme file" This reverts commit 53106e7c470a69562b94372c0576d381e97238b2. * Revert "Added Readme file" This reverts commit 67a2c59241ce976ee866adfbf58e7c7431ff0cda. * Updated the fields and dashboard names * document update * transaction datastream testing * Format changes and ECS version change * doc update * Updated the database name * updated manifest and changelog entreies * renamed sql to mssql & updated 60s * events updated * dashboard changes * Dashboards By Value & updated mb to bytes * Dashboards By Value & updated mb to bytes * visualization by value * visualization by value * updated fields * added dimensions and updated ECS reference * added dimensions and updated ECS reference * Added reference to ECS fields & removed query, driver fields * formating events * pipeline update * Added co-owners * renaming to audit_log * removed query field * updated pipeline * Update stream.yml.hbs * Readme file updated
What does this PR do?
Collects the transaction log metrics for Microsoft Sql server.
Please refer this PR for performance datastream.
Checklist
changelog.ymlfile.MSSQL server integration using generic sql, as per the design doc
How to test this PR locally
Install the MSSQL
Screenshots