AnsweredAssumed Answered

Is there any way to monitor the Replica instance "Administration Activity Monitor"

Question asked by xiaoyun qi on Sep 20, 2017
Latest reply on Dec 11, 2019 by Edward Davis

Like • Show 0 Likes0
Comment • 4

Hi RSA support team

We got a Test Case to Test the account replica from Primary instance to the Replica instance.

the test scenario is when I create a user account in the Primary instance SC console, then there some logs or reportings show up in the Replica instance SC console.

I've tried the reporting function in the SC console

Reporting->real-time Activity Monitors->Administration Activity Monitor

it's only can trace the administration activity(eg.successfully created the"rsa_test" account) in Primary instance,

replica instanc can't trace.

Could u pls help us and give some suggestion?

Thanks and Best Regards

Matt Qi

No one else has this question

Outcomes

4 Replies

David Pala Dec 6, 2019 11:23 AM
Mark Correct
Correct Answer
Hi Matt,
Replicas instances are Read-Only databases.
This is why you cannot trace Administration Activity on those, this would be non-sense.
Administration Activity only occurs on the Primary instance

Kind Regards,
David
Like • Show 0 Likes0
Actions
Jay Guillette Dec 6, 2019 9:30 PM
Mark Correct
Correct Answer
The Replica is read only, and it receives Admin changes like new accounts from the Primary. Replicas also send log data back to the Primary, so you can actually watch replica authentications on the Security Console of the Replica, in real time, same way as on the Primary. SC console
Reporting->real-time Activity Monitors->Authentication Activity Monitor
You can see this because a replica does authentications.

The Admin Changes on the Primary that you describe can be watched in the Primary Real Time Administration Monitor because they take place on the primary. The Primary then puts together a digitally signed change file to be sent to each replica, so that the replica gets the new account. You do not want to try to monitor these changes files, unless you were debugging some tricky replication problem, what you want to do is verify the new account is on the replica. Do that the same way you would on the primary, SC Console - Identity - Manage Users. and look the person up. Or use the Dashboard search. This simple test proves the account created on the primary was replicated to the Replica.

One more note,Checking the Replication Status in the Operations Console is a good way to verify replication is running.

Sometimes you might see replication status is not good, including times when there is a Blue [Sych] button to synchronize the replica to the primary (there is even away to force this button). Clicking this button sends the entire copy of the current database from the Primary to the replica.
1 person found this helpful
Like • Show 1 Like1
Actions
- Piers Bowness @ Jay Guillette on Dec 11, 2019 10:40 AM
  Mark Correct
  Correct Answer
  Just to be clear, Replica databases are technically not read-only; they're just not "writable" from a Replica "Security Console". There are specific database changes (from authentication processes) that are are permitted and replicated.
  Like • Show 1 Like1
  Actions
  - Edward Davis @ Piers Bowness on Dec 11, 2019 11:35 AM
    Mark Correct
    Correct Answer
    To add:
    
    Replicas can do 'some' admin work, and will log it. The goal of a replica though, is dump logs to primary.
    
    One example is Rest API settings. The replica will log it, then try to send the logs to the primary. If a replica is set to send logs to syslog, and if any admin work is done on the replica, the replica admin logs will go to syslog as expected.
    
    example:
    I went to my replica as an admin, and applied the REST API settings to open port 5555 on the OS firewall,
    as this is one of the rare items that is read/write on a replica:
    
    I then get a syslog message from my replica directly, for authmgr.internal.admin.realmmgt event.
    
    So, if a replica does have any read/write administrative setting, it will log it, and....
    
    (a) will send that message via syslog if so configured
    (b) will send that event to the primary if primary is available, then purge it's own logs (as replicas do not
    start collecting logs unless primary is unreachable)
    
    End result is replica is empty of logs, and primary is the place to check admin log history for past admin events on replica (or check your syslog tool as mentioned before). Most admin work you can do on a replica is only on the Operations Console.
    Like • Show 0 Likes0
    Actions

Is there any way to monitor the Replica instance "Administration Activity Monitor"

Outcomes

Related Content

Recommended Content