[fortinet_fortimanager] Update an integration for syslog support

[piyush-elastic]

What does this PR do?

• Updated data collection logic for the log data stream.
• Updated the ingest pipeline for the log data stream.
• Mapped fields according to the ECS schema and added Fields metadata in the appropriate yml files.
• Updated dashboards and visualizations.
• Updated test for pipeline for the log data stream.
• Updated system test cases for the log data stream.

Integration release checklist

This checklist is intended for integrations maintainers to ensure consistency
when creating or updating a Package, Module or Dataset for an Integration.

All changes

• Change follows the contributing guidelines
• Supported versions of the monitoring target is documented
• Supported operating systems are documented (if applicable)
• Integration or System tests exist
• Documentation exists
• Fields follow ECS and naming conventions
• At least a manual test with ES / Kibana / Agent has been performed.
• Required Kibana version set to: ^8.3.0

New Package

• Screenshot of the "Add Integration" page on Fleet added

Dashboards changes

• Dashboards exists
• Screenshots added or updated
• Datastream filters added to visualizations

Log dataset changes

• Pipeline tests exist (if applicable)
• Generated output for at least 1 log file exists
• Sample event (sample_event.json) exists

How to test this PR locally

• Clone integrations repo.
• Install elastic package locally.
• Start elastic stack using elastic-package.
• Move to integrations/packages/fortinet_fortimanager directory.
• Run the following command to run tests.

elastic-package test

Screenshots

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-03-16T13:43:06.159+0000

• Duration: 17 min 55 sec

Test stats 🧪

Test	Results
Failed	0
Passed	10
Skipped	0
Total	10

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

[elasticmachine]

🌐 Coverage report

Name	Metrics % (covered/total)	Diff
Packages	100.0% (1/1)	💚
Files	100.0% (1/1)	💚
Classes	100.0% (1/1)	💚
Methods	100.0% (13/13)	💚
Lines	93.382% (1157/1239)	❕
Conditionals	100.0% (0/0)	💚

[elasticmachine]

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

[efd6]

Maybe rename this file since it is no longer generated data. Suggest name after the version of FortiOS that was the source of the events.

[efd6]

With failable processors it's helpful for debugging to include tags and include those in the appended error message. See discussion here and related proposal here. This adds human/user friendly messages and programmatically amenable tags to error.message. In this particular case it's not so crucial, but there are a few dates and several converts below that would be easier to differentiate with this approach, so I'd suggest doing it for all the failable processors here.

[piyush-elastic]

@efd6, make sense will follow the same and update PR soon. Also do we have any preferred format so that we can follow consistency across all the integration. Some ideas are , consider we have 2 grok processors we can use grok_1 and grok_2 else we can use format {{processor_name_from_source_field_to_target_field}} , let me know.

[elasticmachine]

Package fortinet_fortimanager - 2.0.0 containing this change is available at https://epr.elastic.co/search?package=fortinet_fortimanager