Hi everybody!Something weird happend to me, I have to reinstall one poller of the five of spectrum poller, because hardwre issue, the reinstalation was sucefully. Import db, customization, everything ok.
But when I go to infvoview to run a report for a device from the landscape reinstalled is not showed, then i see, there is no one device from the reinstalled landscape.
I check direcly in the reporting db, and some events and alarms exist, but not outages or another tables, there is "no rows" from the selected landscape.
Is posible fix this without reinitializate the DB, just this landscape. ( I prefer not to.. because there are more than six months of historical data)
Is the restored landscape successfully integrated into your distributed system (DSS)? Can you (in bash shell; bash -login under Windows) cd $SPECROOT/SS-Tools and run;
This will list out if the landscape is part of the DSS. If its not, then best to open a support ticket to investigate why.
Yep, the DSS configuration is without any issue. Right now o leave unchecked this landscape in SPECTRUM Status from report manager option.
If you open the Spectrum Tomcat logs. It would be "Stdout.log" (on Windows) or "catalina.out" (on Linux), do you see this landscape being reported on?
Yes the landscape should be checked in Spectrum Status, only then this would be reported.
Yep, is there with anothers.
from your description this means - the one Landscape install is fresh and new - and the "rest of the DSS" remains. Also the ./MapUpdate -v is fine - means the SpectroSERVERs (here the MLS plus member-servers) can correctly talk to each other.
Question is now - did any hostname or IP-address change - and did you verify the OC/SRM host is part of the new installed SpectroSERVERs $SPECROOT/.hostrc?
Next then is - to do a logon to the OC/SRM webpage - and go to Administation - here finding on the left the "Landscape" item - which should show you all "known" Landscapes (for which you then see a CORBA TCP session using remote(SpectroSERVER) port 14002 (and 14003). That would indicate this OC/SRM Host can truly "talk" to the remote SpectroSERVERs. The "Landscape" item will give you the "Monitored Landscapes (..)" with "Heartbeat Received" update.
Now to over to the dialog -> Adminstration / ReportManager -> SPECTRUM Status
This should show you the same Landscape listing - and here the "missing Landscape" should be "green" and enabled. May you can check this.
In case the SPECTRUM Status indicates that there is no retrieved events/alarms - but the status is "enabled" and "green" - then this indicates this Landscape is not in "logical sync" with the existing Landscape data which is already in the "reporting database". Here please refer to the CA Spectrum manuals - which will suggest to initialize this Landscape data - and then to get the OC/SRM reporting database resynced (here use parameter -initHist for the reportmanager initalization command.
See/Find infos here too:
Tech Tip: How to initialize the Spectrum Report Manager (SRM) database.
Kind regards, Joerg
Thanks, for reply. one (of five) landscape was reinstalled in a new fresh server, all backup, custom conf, was uplodas correctly.
spectrum "Heartbeat Received" and ok
spectrum report manager status is "enabled" and "green" and to date. same as others.
but running reports this reinstalled landscape is not enable.
seeing directly to mysql there are date such as events, alarms, in reporting db, but in srmdbapi there is no outages or models, or another records from this landscape.
Yesterterday I ran
./RpmgrInitializeLandscape.sh root root 0x500000 ./SMInitializeLandscape 0x500000
./RpmgrInitializeLandscape.sh root root -initHist 45 0x500000
And now I have it working again, but without the historical data, and without brake anything from others landscapes.
please make use of parm "-initHist" - what this does it; it set's back the "sync" date/time to "now - <initHist_days>"
and by this - the OC/SRM will start to resync to the SpectroSERVER with it's ArchiveManager data (this is the mysql "ddmdb" - saved at SpectroSERVER level). Here it is the ./SS/DDM/.configrc -> MAX_EVENT_DAY parm which controls the FIFO/aging logic for the ArchiveManger. So if you have "data" still in the "ddmdb" / ArchiveManager - then it can catch up with them so you have some history.
yep, but only what is in DDMDB, is it posible reinitialize it keeping historical data in reporting db ? maybe not.