Guide to migrate Centralized Logging with OpenSearch (CLO) v1.0.3 to v2.0.0 #184
Replies: 3 comments 3 replies
-
TODO
Log hub upgrade to guide #85 Log Hub version list
v1.0.0..v1.0.1
v1.0.1..v1.0.3
v1.0.3..v1.1.0
v1.1.0..v1.2.0
v1.2.0..v1.2.1
|
Beta Was this translation helpful? Give feedback.
-
前期调研
如果版本差异太大,比如:Loghub v1.2.2 升级到 CLO v2,建议同时部署 CLO v2 和 Loghub v1.2.2 版本,然后逐步把配置从老版本抄到新版本里面! 拆除重建步骤
|
Beta Was this translation helpful? Give feedback.
-
I'm currently using version 1.0.1. After updating to 2.0.0, to update to 2.0.1 is only a matter of updating the template as well? |
Beta Was this translation helpful? Give feedback.
-
Prerequisites
The following is log hub version list, the last log hub version is v1.2.1.
Overview of Steps
CrossAccount.template
stack in each member account. And link member account in v2.0.0 console. (optional if you don't have member account)Operational Steps
Update CLO v1.0.3 to v1.0.4 using CloudFormation update stack.
In CFN, locate the stack for CLO v1.0.3, click "update," and update it to version v1.0.4. The main purpose of this step is to prevent essential resources (such as VPC and KMS Key) from being deleted upon stack removal.
Depending on whether the CLO v1.0.3 template is for a new VPC or OIDC, select the corresponding v1.0.4 version.
Deploy CLO v2.0.0 in the same region as CLO v1.0.3.
Choose the version of CLO v2.0.0 based on the following scenarios:
If v1.0.3 was deployed using a new VPC version (template name does not contain "FromExistingVPC"), deploy the v2.0.0 version of CentralizedLoggingFromExistingVPC.template or CentralizedLoggingFromExistingVPCWithOIDC.template. In this case, use the VPC and Subnets parameters from the v1.0.3 deployment. Refer to the provided images for relevant information.
If v1.0.3 was deployed using the FromExistingVPC version (template name contains "FromExistingVPC"), deploy the v2.0.0 version of CentralizedLoggingFromExistingVPC.template or CentralizedLoggingFromExistingVPCWithOIDC.template.
Manually migrate the syslog pipeline (optional).
Automatic migration of syslog logs is currently not supported. To migrate the syslog pipeline from v1.0.3, follow these steps:
Deploy the migration tool CFN stack in the same region.
Deploy
CrossAccount.template
stack in each member account. And link member account in v2.0.0 console. (optional if you don't have member account)CrossAccount.template
file into your local machine.":role/CL-EKS-LogAgent-Role-*"
into":role/*-EKS-LogAgent-Role-*"
.CrossAccount.template
as usual.Manually update the EC2 Instance Profile / ASG IAM role policy.
Due to slight changes in the EC2 Instance profile in v2.0.0, navigate to the Instance group panel in the v2.0.0 CLO console, find the Instance Permission Policy, and manually add it to the IAM Role of each machine in the Group. It's recommended to create this policy using the "Create inline policy" option.
Verify the post-deployment functionality.
Check the availability of features in the v2.0.0 CLO console and ensure that OpenSearch is continuously collecting data. Contact Support if any issues arise.
Delete the migration tool CFN stack.
Delete the CLO v1.0.3 stack.
It is recommended to observe the operation of v2.0.0 for approximately two weeks after migration. If everything is functioning properly, you can proceed to delete the CLO v1.0.3 CFN stack. The migration process is now complete.
Known Issues
After Service/App pipeline migration, the Lambda Processor log-related panel does not display data.
Due to the pipeline originating from v1.0.3, metrics for log volume of v1.0.3 log pipelines are currently not observable. This is normal behavior. If you wish to see this data, delete the existing pipeline and create a new one.
Is cross-account migration supported?
Yes, You need to manually Deploy
CrossAccount.template
stack in each member account. And then re-link member account in v2.0.0 console.The admin password is changed after migration to CLO v2.0.
This is by design. If you are deploying with a non-OIDC template. The CLO creates the Cognito UserPool for you to manage Admin usernames and passwords. The migration tool won't migrate Cognito User Pools data. So you must log in to the CLO console with a new username and password.
An error occurred (AccessDenied) when calling the ListRolePolicies operation: User: arn:aws:sts::*****:assumed-role/clo-amp-prod-APIAppPipelineAPIAppPipelineHandlerSer-bUXDfcDRJqhO/clo-amp-prod-APIAppPipelineAPIAppPipelineHandler49-otQV7Zs3oHKe is not authorized to perform: iam:ListRolePolicies on resource: role LogHub-AppPipe-f17c7-BufferAccessRoleDF53FD85-1OOE1J2AW7TQC because no identity-based policy allows the iam:ListRolePolicies action
This is due to the fact that you are deleting the LogHub v1.x Pipeline in CLO v2.0, and the naming of the Role has changed significantly due to the version difference. The upgrade we have tested so far is from CLO v1.x to CLO v2.x, which requires all Pipeline resources to be created in CLO v1.x instead of LogHub version. To resolve this issue, it is recommended that you remove this Pipeline from the LogHub console and then remove this record from the AppPipeline DynamoDB Table.
Beta Was this translation helpful? Give feedback.
All reactions