Problème récupération données
Closed this issue · 20 comments
Bonjour,
J'obtiens des erreurs de récupération de données.
Les XML se génèrent bien sur le serveur, j'ai limité l'historique, le fichier backupsession fait 175Mo.
Je récupère bien l'état d'une sauvegarde.
Que faut il regarder ?
Je viens de tester l'execution d'un zabbix_get -s IP -k 'vbr[ResultReplica,ID]'.
Cela fonctionne 1 fois sur 3-4.
Par contre, cela mets plus de 24-25 secondes lors que ça marche.
Je pense que le script met trop longtemps à répondre.
Comment améliorer les temps de réponses sachant que l'agent ne tolère pas plus de 30 secondes ?
Le serveur ne présente pas de problèmes de ressources.
Bonjour,
Pas de problèmes d'I/O disque ?
Le serveur & l'hote sont sur le même LAN ?
Pour récupérer la valeur le script lance uniquement cela :
$xml = ImportXml -item backupsession
$query1 = $xml | Where { $_.jobId -like "$ID" } | Sort JobStart -Descending | Select -First 1
$query2 = $query1.Result
if (!$query2.value)
{
write-host "4" # If empty Send 4 : First Backup (or no history)
}
else
{
$query3 = $query2.value
$query4 = "$query3" | veeam-replace
write-host "$query4"
}
En gros il importe le fichier xml et fait un filtre dessus.
2/3s généralement pour avoir le retour ...
Pour voir le temps de traitement pour chaque commandes vous pouvez essayer sa en powershell :
$ID = 'IciUnIdDeTacheReplica'
cd 'C:\Program Files\Zabbix Agent\scripts\TempXmlVeeam'
$xml = Import-CliXml .\backupsession.xml
$query1 = $xml | Where { $_.jobId -like "$ID" } | Sort JobStart -Descending | Select -First 1
write-host "$query1.Result"
Merci pour le retour.
J'ai testé le script en powershell, pas contre, je comprends pas, il me retourne simplement :
Veeam.Backup.Core.CBackupSession.Result
Le script mets 20sec à répondre.
Le serveur n'a pas de problème d'IO, il est plus sollicité par moment que d'autre mais le problème se présente 24h/24 soit meme lorsqu'il est inactif.
Il s'agit d'un serveur physique avec 4 disques en RAID.
Dans mon fichier, il me trouve 3000 occurences de cet id.
Le pb vient peut etre de là non ?
J'ai déjà diminué pour ne garder que 53 semaines passant de 450Mo à 175Mo
Bonjour,
Pouvez vous essayer après le scripts ci-dessus d'afficher le contenu de la variable $query1 et de me la renvoyer ?
Bonjour,
comment dois je procéder pour afficher le contenu ?
Je n'obtiens que "Veeam.Backup.Core.CBackupSession.Result" en réponse sur le terminal
Voir script ci-dessous :
$ID = 'IciUnIdDeTacheReplica'
cd 'C:\Program Files\Zabbix Agent\scripts\TempXmlVeeam'
$xml = Import-CliXml .\backupsession.xml
$query1 = $xml | Where { $_.jobId -like "$ID" } | Sort JobStart -Descending | Select -First 1
write-host "$query1"
Je viens d'executer le script ci-dessus avec un Id de replica.
J'obtiens :
Veeam.Backup.Core.CBackupSession
Je colle le script dans le Powershell ISE sur le serveur veeam et je l'exécute.
Est ce que ma procédure est la bonne ?
Je me demande si les xml contiennent bien les valeurs ...
Oui dans ISE sur le serveur Veeam c'est la bonne procédure ;)
Peut tu essayer d'afficher le contenu du xml comme celà : (sa peut sortir beaucoup d'info mais le but est de savoir si le xml contient les vrais valeurs)
$ID = 'IciUnIdDeTacheReplica'
cd 'C:\Program Files\Zabbix Agent\scripts\TempXmlVeeam'
$xml = Import-CliXml .\backupsession.xml
$xml
Le script retourne un paquet d'enregistrement.
Le dernier enregistrement est celui-ci:
EventNotifier : Veeam.Backup.Core.CEventNotifier
BottleneckManager : CJobBottleneckManager
Info : Veeam.Backup.Model.CBackupSessionInfo
Progress : Veeam.Backup.Model.CBackupProgressData
StartupMode : Normal
JobSourceType : VDDK
CurrentPointId : 00000000-0000-0000-0000-000000000000
OriginalSessionId : 81e1975f-5202-4b07-aca0-ffffcaf052ba
ParentSessionId : 00000000-0000-0000-0000-000000000000
IsFullMode : False
IsRetryMode : False
IsRecheckRetry : False
IsQuickBackup : False
IsVeeamZip : False
IsPlannedFailover : False
IsReplicaFromBackup : False
IsEpAgentManagement : False
PostActivity : AskService
Name : Replication VM impact haut (Incremental)
OrigJobName : Replication VM impact haut
BackupStats : Veeam.Backup.Model.CBackupStats
WorkDetails : Veeam.Backup.Core.CBackupSessionWorkDetails
WillBeRetried : False
IsManuallyStopped : False
IsTransformLaunched : False
LastProgressSaveTime : 01/01/0001 00:00:00
SessionCryptoSpec : Veeam.Backup.Crypto.CCryptoSymmetricSpec
UserKey :
MasterKey : Veeam.Backup.Core.CCryptoKey
UserCryptoSpec :
SelectiveProcessingSpec :
BackupVerificationResult : Veeam.Backup.Core.CBackupVerificationResultContainer
IsEncryptionEnabledByOptions : False
IsEncryptionEnabled : False
SplitStoragesPerVm : False
DataBag : {}
SessionInfo : Veeam.Backup.Model.CBackupSessionInfo
Id : 81e1975f-5202-4b07-aca0-ffffcaf052ba
LeaseId : 00000000-0000-0000-0000-000000000000
JobType : Replica
JobName : Replication VM impact haut
JobSpec :
JobTypeString : Replication
CreationTimeUTC : 27/04/2019 08:00:06
Operation :
Description :
BaseProgress : 100
IsCompleted : True
IsWorking : False
IsStarting : False
IsPostprocessing : False
JobId : 5426f9f0-106c-482a-9341-a8786374bc10
Result : Success
State : Stopped
EndTime : 27/04/2019 08:07:06
EndTimeUTC : 27/04/2019 08:07:06
CreationTime : 27/04/2019 08:00:06
AuxData : 271089116271089116100</Dedup
Ratio>1004198486396</W
orkDuration>
IsLowerAgentPriority : False
LogName : Job.Replication_VM_impact_haut
LogsSubFolder : Replication_VM_impact_haut
Logger : Veeam.Backup.Core.XmlLogger
Tracer : Veeam.Backup.Core.CSessionLogTracer
Ok je pense voir le problème.
Le script classe les sessions par ordre du dernier job lancé (jobstart) mais les backupsessions utilise la date de création de la tâche lancée il faut donc que le script classe par creationtime.
Bref ^^
Je modifie le script et le release de suite sinon il suffit de modifier la ligne 529 par celle là :
$query1 = $xml | Where { $_.jobId -like "$ID" } | Sort creationtime -Descending | Select -First 1
Merci
J'ai récupéré le nouveau script mais cela n'améliore pas beaucoup le problème.
J'ai gagné un peu en temps de réponse apparemment mais pas suffisamment.
Ne peut on pas limiter la taille du xml au moment de la génération de celui-ci en ne récupérant que les 100 derniers jobs par exemple sans réduire les logs de veeam ?
Zabbix se chargera de stocker l'historique.
Bonjour,
La modification du script concerner les résultats de réplications, pas le temps de d’exécution.
Pour réduire le nombre d'entrées dans le XML, il suffit de modifier la variable $days ligne 70 du script qui permet de de réduire/augmenter l'historique des sessions.
Attention tout de même car si il est réduit à 10 jours par exemple et que le réplica s’exécute tous les 11 jours il n'y auras pas de valeurs ...
Bonjour,
N'est il pas possible de limiter à X resultats par job, plutôt que par la durée ?
Cela permettrait d'alléger les xml.
Bonjour,
Pour les réplica sa pourrait aller mais pour les Backups Sync par exemple le fonctionnement est différent et oblige de remonter sur plusieurs sessions pour gérer les retry pour chaque VMs.
Cela me parait compliqué ...
Bonjour,
Dans mes logs Zabbix, j'ai ca :
Zabbix agent item "vbr[VMResultBackup,"Machine","Backup Full-Machine"]" on host "serveurveeam" failed: first network error, wait for 15 seconds
Lorsque j'execute la requete, j'ai la réponse en 15sec.
Je comprends pas.
Bonjour,
La directive timeout de zabbix_agentd.conf a bien été renseignée ?
Pouvez vous la mettre à 30s et penser à redémarrer le service zabbix_agent ?
Bonjour,
Je l'ai déjà fait, je viens de vérifier.
L'agent a également été redémarré dans les services.
Je vous invite à modifier la partie serveur également :
By default, both agent and server had Timeout = 3. For agent, it defines maximum time to wait for item checks. For server, it defines how long to wait for agent, SNMP device or external check.
Ah super.
En effet, ca va beaucoup mieux.
Toutes les infos remontent.
Merci infiniment pour le travail et le support.
(Il faudra peut être rajouter dans la documentation qu'il faut passer le timeout de l'agent et du server, sauf si déjà présent et que je l'ai zappé)
Il n'était pas présent dans la doc, je l'ai ajouté pour les prochains ;)
Top bonne continuation !