Thanos compactor en PLS sur S3
Commentaires
"AccessDenied" sur S3 c'est souvent un souci de policy IAM ou d'ACLs si le bucket a été créé avec des settings bizarres. t'as vérifié les bucket policies et les ACLs du bucket ?
les "nosuchkey" peuvent indiquer que le compactor essaie de gérer des blocks que les sidecars ont pas fini d'uploader ou qu'il y a un décalage de temps. les horloges de vos machines sont synchronisées (ntp) ?
bucket policy et ACLs sont standard. j'ai même mis un rôle full access pour tester et ça le fait toujours. ntp est nickel.
si c'est aléatoire c'est chelou. "NoSuchKey" peut aussi venir si le "compactor" essaie de lire un segment d'un block qui a été compacté juste avant par un autre "compactor" ou qu'il y a plusieurs "compactor" qui tournent et se marchent dessus ?
on a qu'un seul "compactor" qui tourne. on a aussi vu des "s3:ListBucket" permission denied alors que la policy est là.
ah "listbucket" deniée alors que c'est dans la policy c'est un red flag. est-ce que le bucket est chiffré par kms et le rôle du compactor a pas la permission "kms:decrypt" ? ou un "deny" explicite qqpart ?
le bucket n'est pas chiffré KMS. et j'ai fait un "iam policy simulator" et le rôle est censé avoir toutes les perms. je comprends rien.
t'as des "bucket versioning" ou "object lock" activés ? ça peut créer des comportements inattendus avec des clients qui s'attendent pas à gérer plusieurs versions d'objets ou qui ont des problèmes pour delete
oui le versioning est activé sur le bucket. ça pourrait être ça ?
absolument ! avec le versioning activé, un "DeleteObject" sans spécifier l'ID de version crée juste un "delete marker" et l'objet n'est pas vraiment supprimé. le "compactor" pourrait être confused par ça ou si il essaie de réécrire un objet avec le même nom mais pas la bonne version.
le "compactor" doit gérer le versioning correctement. tu as quelle version de Thanos ? ça a été corrigé dans les versions récentes il me semble.
Thanos 0.31.1. c'est la dernière stable. donc ça devrait gérer le versioning.
hmm si 0.31.1 est censé gérer le versioning, est-ce qu'il n'y aurait pas un préfixe d'objet que le compactor essaie de supprimer et qui est protégé ou n'existe pas vraiment ? genre des blocks corrompus ?
et les credentials ? si t'utilises des "access_key"/"secret_key" statiques, t'es sûr qu'elles sont bonnes et pas révoquées/expirées temporairement ?
j'ai re-généré les clés pour être sûr. j'ai désactivé le versioning sur un bucket de test et miracle le compactor n'a plus eu de soucis. donc c'est bien lié au versioning.
ok donc un bug avec le versioning même sur la 0.31.1 ou une interaction chelou. tu peux ouvrir une issue github chez thanos. pour l'instant désactiver le versioning ou utiliser un lifecycle policy pour purger les vieilles versions c'est une solution.
ouais c'est le workaround classique. bien vu.
merci les gars c'était bien le versioning s3. je vais le désactiver pour l'instant et ouvrir une issue sur le repo thanos. vous m'avez sauvé la mise encore une fois !
Laisser une réponse
Vous devez être connecté pour poster un message !
Rejoindre la communauté
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
matthieu86
Membre depuis le 13/05/2019
actif
salut les observability addicts. on a un souci récurrent avec notre setup thanos. le "thanos compactor" crache des erreurs s3 genre "accessdenied" ou "nosuchkey" de façon aléatoire alors que le "sidecar" des prometheus écrit bien les blocks. les buckets sont sur aws s3 avec des rôles iam qui ont les bonnes permissions (s3:getobject, putobject, deleteobject, listbucket). y'a que le compactor qui chiale et pas tout le temps. des idées ?