[Azure Logs] Rebrand azure spring cloud logs to azure spring apps logs

[muthu-mps]

• Enhancement

Proposed commit message

This PR updates the Azure Spring Cloud Logs to Azure Spring Apps Logs as per the change mentioned here

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.

How to test this PR locally

• Install the Azure Spring Cloud Logs integrations and upgrade the integrations and verify the data is getting loaded in the dashboards.
• Check the older name gets replaced with the newer name in all the places.

• Verify the changes in the following places

  • Documentation
  • Add Integrations page
  • Dashboard title, description, Visualisation title

Related issues

• Closes [Azure] [Logs] Rebrand Azure Spring Cloud to Azure Spring Apps #4111

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-10-17T03:57:38.526+0000

• Duration: 14 min 17 sec

Test stats 🧪

Test	Results
Failed	0
Passed	83
Skipped	0
Total	83

🤖 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% (10/10)	💚
Files	86.364% (19/22)	👎 -13.636
Classes	86.364% (19/22)	👎 -13.636
Methods	83.333% (155/186)	👎 -9.016
Lines	85.021% (2821/3318)	👎 -6.567
Conditionals	100.0% (0/0)	💚

[zmoog]

I see we are changing the labels and the description with the new "Spring Apps" name, which is good.

The data stream name, the dataset, and the fields keep the old azure.springcloudlogs name?

[muthu-mps]

I see we are changing the labels and the description with the new "Spring Apps" name, which is good.

The data stream name, the dataset, and the fields keep the old azure.springcloudlogs name?

When we change the datastream name this will add a new service in the UI. The existing users might not be able to update the service from the older version to newer version.

If we try to change the field name then this will become a breaking change. When making this change we have to consider the Kibana dashboards updated with the new field names. Can we have aliases for the fields this would help maintain consistency while searching for data from older fields and from the newer fields?

Also the event.dataset filter should be applied with older and newer names to render the data ingested from older version and with the newer version.

@zmoog - If we change the datastream name to a new name, Will the policy template work for updating the existing integration ? Can we consider changing the field name and the datastream names?

[zmoog]

Hey @muthu-mps, the same questions stopped me from completing the previous PR on this topic.

Changing the data stream name from azure.springcloudlogs to azure.springappslogs would probably result in a breaking change.

We can approach this at the branding level only or go deeper:

1. Branding only: update the externally visible names to "Spring Apps" and keep internal names (fields, data stream, etc) to the old name — what this PR is doing.
2. Go deeper: replace "spring cloud" with "spring app" internally and externally.

What's your take from the product perspective, @SubhrataK ?

@muthu-mps, one option I contemplated back in the day was to add a new integration named "Spring Apps" and mark "Spring Cloud" as deprecated; this may be a compelling option, especially if we can add an alias for the older azure.springcloudlogs. fields in the new integration: do you know if aliasing works across different data streams?

[muthu-mps]

@zmoog - As per the recent discussions with @SubhrataK , We can go-ahead with renaming the application externally. Hope this helps!

[zmoog]

@muthu-mps, if @SubhrataK wants to focus on external rebranding, this PR is spot-on.

Nit: we may consider updating the inner pipeline description at

integrations/packages/azure/data_stream/platformlogs/elasticsearch/ingest_pipeline/springcloudlogs-inner-pipeline.yml

Line 2 in 6f9073c

description: Pipeline for parsing azure spring cloud logs.

.

For a reason I don't know, we have a copy of the Spring Apps logs embedded in the platform logs integration. My wild guess is that this is to support better the Native Azure Integration that has limited routing capabilities, but I am unsure. Maybe @hemantmalik knows more about this backstory.

We can drop the Spring Apps logs pipeline embedded in the platform logs as we add routing rules capabilities to the Azure Logs integration. More on this topic soon.

[muthu-mps]

For a reason I don't know, we have a copy of the Spring Apps logs embedded in the platform logs integration. My wild guess is that this is to support better the Native Azure Integration that has limited routing capabilities, but I am unsure. Maybe @hemantmalik knows more about this backstory.

We can drop the Spring Apps logs pipeline embedded in the platform logs as we add routing rules capabilities to the Azure Logs integration. More on this topic soon.

Thanks @zmoog! Let me verify the reason for embedding in platform logs.

[zmoog]

Thanks @zmoog! Let me verify the reason for embedding in platform logs.

I guess we added it back in the day to process spring cloud logs coming from the Native Azure Integration.

We can't remove it until we add routing rules.

[elasticmachine]

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