How to trace .NET webrequests

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
    </startup>
<system.diagnostics>
        <trace autoflush="true" />
        <sources>
            <source name="System.Net" maxdatasize="1024000">
                <listeners>
                    <add name="MyTraceFile"/>
                    <add name="MyConsole"/>
                </listeners>
            </source>
        </sources>
        <sharedListeners>
            <add
              name="MyTraceFile"
              type="System.Diagnostics.TextWriterTraceListener"
              initializeData="System.Net.trace.log" />
                <add name="MyConsole" type="System.Diagnostics.ConsoleTraceListener" />
        </sharedListeners>
        <switches>
            <add name="System.Net" value="Verbose" />
        </switches>
    </system.diagnostics>  
  <system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding name="SoapBinding">
          <security mode="Transport" />
        </binding>
      </basicHttpBinding>
    </bindings>
    <client>
      <endpoint address="https://eu5.salesforce.com/services/Soap/c/33.0/00000000000000001"
          binding="basicHttpBinding" bindingConfiguration="SoapBinding"
          contract="Soap" name="Soap" />
    </client>
  </system.serviceModel>
</configuration>

--
public final static void main(String[] args) throws Exception {
File f = new File("C:\\System.Net.trace.log");
BufferedReader br = new BufferedReader(new FileReader(f));
String line = br.readLine();
boolean started = false;
StringBuffer sb = new StringBuffer();
while (line!=null) {
if (line.contains("<s:Envelope")) {
started = true;
}
int idx = line.lastIndexOf(" : ");
if (idx != -1)
line = line.substring(idx + 3);
if (started) {
sb.append(line.trim());
if (sb.indexOf("</s:Envelope")!=-1) {
started = false;
System.out.println(sb.toString());
sb.setLength(0);
}
}
line = br.readLine();
}
br.close();
}
}

How to get Hawk JMX data from BW

try {
    Set<objectinstance> result = conn.queryMBeans(new ObjectName("com.tibco.bw:key=engine,name=*"), null);
    if (result.size() > 0) {
     ObjectInstance tib = result.iterator().next();
     TabularDataSupport getActivities = (TabularDataSupport) conn.invoke(tib.getObjectName(), "GetActivities", new Object[] { null }, null);
     TabularDataSupport getProcesses = (TabularDataSupport) conn.invoke(tib.getObjectName(), "GetProcesses", new Object[] { 0, null, 0, 0, null }, null);
           
 for (Object _row : getProcesses.values()) {
     BWStats bw = new BWStats();
            CompositeData row = (CompositeData)_row;
            bw.process = (String) row.get("MainProcessName"); 
            bw.activity = (String) row.get("CurrentActivityName");
            bw.clazz = "IN";
            bw.status = (String) row.get("Status");
            bw.duration0 = (Long) row.get("Duration");  
            stats.bwStats.add(bw);
        }
           
        for (Object _row : getActivities.values()) {
            CompositeData row = (CompositeData)_row;
            BWStats bw = new BWStats();
            bw.process = (String) row.get("ProcessDefName"); 
            bw.activity = (String) row.get("Name");
            bw.clazz = (String) row.get("ActivityClass");
            bw.duration0 = (Long) row.get("ExecutionTime");
            bw.duration1 = (Long) row.get("ElapsedTime");
            bw.count = (Long) row.get("ExecutionCount");   
            stats.bwStats.add(bw);
    }
}
catch (Exception exc) {}

Koszty utrzymania projektów Tibco

Jak uczciwie wystawić biznesowi rachunek za koszty infrastrukturalne? Każdy proces BW i każdy przepływ powinny generować zdarzenia "użycia". Zużycie procesora w zadanym czasie może być wyjęte za pomocą JMX-a. Mierząc czasy poszczególnych zadań i dysponując zużyciem procesora w oknie czasowym je obejmującym można oszacować zużycie procesora przez pojedyncze zadanie. Mając statystki procesora, pamięci, przestrzeni przechowywania danych można obliczyć realne koszty zadań Tibco. Mierząc i analizując czasy trwania procesów (średnia, mediana, percentyle: 90, 95, 99) przez dłuższy okres można ocenić wpływ wdrażanych projektów na pozostałe i wyciągać wnioski, czy dla spełnienia starych SLA konieczne jest zwiększenie zasobów przy uruchamianiu nowych projektów. Mając dokładne dane, biznes wie za co płaci. Kosztowne pod względem infrastruktury projekty można przepisać i przez to zoptymalizować.

Skuteczny monitoring EAI

• logi błędów przetwarzane są automatycznie i na ich podstawie generowane są alerty (mail, sms)
• alert zawiera link do dokumentacji komponentowej (jeśli w bazie reguł nie ma poprawnego linku, problem 'za karę' obsługuje przełożony utrzymania)
• dokumentacja komponentowa to jeden dokument MS Word/Open Document, w którym można zrobić Ctrl+F po znaczącej frazie z alertu i w ten sposób zobaczyć znane problemy i obejścia
• dokumentacja komponentowa zawiera miesięczny grafik wsparcia: osoba obsługująca + osoba zapasowa (jeśli wpisy nie są poprawne, problem 'za karę' obsługuje przełożony utrzymania)
• monitoring i wsparcie powinno opierać się na wyuczonych, ustandaryzowanych, procesowych procedurach postępowania

O monitoringu EAI

Jeśli mamy w miarę homogeniczną platformę integracyjną (ta sama technologia i zbliżone wersje oprogramowania), to powinna ona mieć monitoring automatyczny. Zatrudnienie ludzi do zadań 24/7 to strata pieniędzy i jakości. Pieniędzy dwa razy, bo opłacany jest człowiek, który na nocnej zmianie śpi, ogląda youtube-a i inne tube-y..., ściąga torrenty itd., a pojedyncze błędy traktuje jako rzecz nie wymagającą raportowania - po paru dniach przychodzi z tą rzeczą biznes, kiedy aktualna strata z powodu niedziałania przepływu przewyższa pensję monitoranta. Dojrzałe EAI ma monitoing automatyczny, wrzucający zdarzenia do bazy, gdzie obrabia je silnik reguł, w razie potrzeby rejestruje w systemie zarządzania incydentami, wysyła odpowiednim osobom maile i sms-y, zapala światełka na czerwono. Monitoring powinien być proaktywny, czyli np. wywoływać co jakiś czas usługi i sprawdzać, czy otrzymana odpowiedź jest poprawna. Do powiadamiania sms-ami o awarii można wykorzystać przemysłowy modem gsm.

Statystyki z Tibco

Statystyki procesów Tibco są w czasie zbliżonym do rzeczywistego pakowane do bazy danych. Powinien to być Oracle na bardzo silnej maszynie. Dane obrabiane są przez aplikację webową. Parę wykresów dla benchmarku EMS:

Wartości odstające od reszty to procesy z aktywnościami JMSQueueSend. Wysyłanie komunikatów odbywa się równolegle z ich odbieraniem. Wśród dużych wartości można wyodrębnić dwie grupy - bo mamy procesy wysyłające wiadomości 16k i 128k.

Średni czas między wysłaniem komunikatu JMS a odebraniem go przez proces to 100ms.

W różnicy JMSExpiration i czasu zakończenia procesu nie widać nic niepokojącego.

Jeśli tabelkę ze statystyką procesu uzupełnimy o kolumny: czas startu dzielony przez 3 minuty, 30 minut, 4 godziny, 1 doba, na których mamy indeksy to będziemy mogli zrobić szybką analizę po oknach czasowych.

Instrumentacja Tibco

Z działające instancji BW wyjmujemy takie dane jak liczba utworzonych, zakończonych, uruchomionych zadań, FlowLimit, znacznik czasu rozpoczęcia i zakończenia procesu, liczba użytych wątków systemu operacyjnego dla puli danego zadania, nagłówki JMS. Dane wysyłane są uproszczonym protokołem SOAP po stale utrzymywanym połączeniu HTTP. Po drugiej stronie odbiera je Netty. Przy kodzie wysyłającym i odbierającym uruchomionym w tym samym procesie BW narzut w najgorszym przypadku to 7,5% (zmierzone za pomocą crash-benchmarku EMS, realnie 2%). Przy wykorzystaniu procesora poniżej 100% narzut powinien być prawie niewidoczny.

Monitoring na sms-a

Kupujemy modem GSM, podłączamy go do linuksowego serwera, stawiamy na serwerze bramkę mail-sms, a potem już tylko:

HOSTNAME=`hostname`
USER=`whoami`
SMTP="10.10.1.25"

function sendmail {
   (
       sleep 3
       echo "HELO $HOSTNAME"
       sleep 1
       echo "mail from: monitoring@email.com"
       sleep 1
       echo "rcpt to: smsgw@email.com"
       sleep 1
       echo "data"
       sleep 1
       echo "From: monitoring.$USER@email.com"
       sleep 1
       echo "To: smsgw@email.com"
       sleep 1
       echo "Subject: $1"
       sleep 1
       echo ""
       sleep 1
       echo "$2"
       sleep 1
       echo "."
       sleep 1
       echo "quit"
       sleep 1
   ) | telnet $SMTP 25
}

sendmail "$1" "$2"

# ./sendsms "+48602201122" "Brak dzialajacego procesu A dla systemu B"

Naprawiona biblioteka libIntroscopeRedHatStats.so

Idea poprawki polega na stworzeniu proxy na bibliotekę i własnej implementacji metody getAggregateCPUUsage.

Pozostałe funkcje JNI można prawdopodobnie zaimplementować następująco:

getProcessCPUUsage -> getrusage()
getTotalClockTicks -> clock()
isThreadCpuTimeEnabled -> defined RUSAGE_THREAD
getThreadCpuTime -> getrusage(RUSAGE_THREAD, &usage)

Update: Przepisałem całą bibliotekę, gdyby ktoś chciał binarkę prośba o kontakt.

JRockit Mission Control

Śledzimy fragmentację...
JAVA_OPTS="-Xms384M -Xmx384M -Xmanagement:ssl=false,authenticate=false,autodiscovery=true"
JROCKIT_OPTS="-Xgc:genpar -XXcompactRatio:100"
JROCKIT_OPTS="-Xgc:singlecon -Xns32m -XXcompactRatio:100 -XXtlaSize:min=128K,preferred=512K -XXlargeObjectLimit=128K"



jrcmd 0 start_management_server
jrcmd 0 start_rmp_server

Analiza zmian po instalacji

Narzędzie TrackWinstall pozwala na porównanie stanu systemu sprzed instalacji danego programu ze stanem po instalacji. Narzędzie analizuje Rejestr oraz katalogi Windows i Documents and Settings. Żeby porównać inne katalogi można posłużyć się narzędziem junction od SysInternals i w katalogu Windows stworzyć hardlinka.

Statystyki SVN

svn log -v --xml ../projects/projekt > log_projektu.log;
java -jar ../statsvn.jar log_projektu.log ../projects/projekt



Narzędzie jest darmowe z SourceSorge'a, potrafi wizualizować parę fajnych rzeczy. Przydaje się zaganianemu kierownikowi projektu w sprawdzeniu, co robią jego deweloperzy.

Prosty skrypt do przyrostowego monitorowania logów

#!/bin/sh
function check_log() {
  logfile="$1"
  pattern="$2"
  if [[ -z $pattern ]] ; then
      echo "Wzorzec do wyszukiwania nie moze byc pusty"
      return 1
  fi
  if [[ -f $logfile ]] ; then
      size=`LC_ALL=C stat ${logfile} | grep Size | cut -d" " -f4 2>/dev/null`
      old_size=`cat $logfile.size 2>/dev/null`
      diff=`expr $size - $old_size 2>/dev/null`
      if [[ -z $diff ]] ; then
          diff=$size
      fi
      if [[ $diff -lt 0 ]] ; then
          diff=$size
      fi
      if [[ $diff -gt 0 ]] ; then
          echo "Plik zmodyfikowany, roznica $diff bajtow"
          tail -c $diff $logfile | grep -A 20 -B 5 -e "${pattern}" 2>/dev/null 1> $logfile.err
          cat $logfile.err
      else
          echo "Plik bez zmian, rozmiar $size"
      fi

      echo "$size" > $logfile.size
  else
      echo "Nie ma takiego pliku $logfile"
  fi
}

logfile="/home/weblogic/bea/domains/WebPortal/servers/WebPortalServer1/logs/WebPortalServer1.out"
pattern="Exception"
check_log $logfile $pattern

WJMX i WebLogic 10

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=8888
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

service:jmx:rmi:///jndi/rmi://192.168.1.100:8888/jmxrmi

JConsole i WebLogic

JConsole z JDK 1.6 ma problemy przy odczycie danych, wypada używać wersji 1.5. Adres jest typu: 'service:jmx:iiop:///jndi/iiop://wlserver:7001/weblogic.management.mbeanservers.runtime'.

VisualVM od Sun-a

Dostępny w JDK 1.6.07 albo oddzielnie.

Jak profilować WebLogic-a

Ściągamy YourKit Java Profiler, wgrywamy bibliotekę agenta na maszynę z WLS i w zakładce ServerStart podajemy '-agentpath:/home/weblogic/ykjprofiler/libyjpagent.so=port=9999'